> ## Documentation Index
> Fetch the complete documentation index at: https://lnurl.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# LUD-13: `signMessage`-based seed generation for auth protocol.

> Display inline code and code blocks

`author: akumaigorodski` `author: fiatjaf` `author: hampus_s` `discussion: https://t.me/lnurl/5155`

***

## Seed generation method for the auth protocol

This is based on the `signmessage` API provided by some Lightning node implementations. It signs an HMAC of a message in a standard way using ECDSA with deterministic nonces, so it's always the same signature given the same key and message.

Here we define a canonical phrase to be signed, and from that we will derive the LNURL-auth seed.

### `linkingKey` derivation for wallets which don't have an access to master `privKey`:

In this case neither `hashingKey` nor domain-specific `linkingKey`s can be derived by the path. To overcome this limitation a different scheme is used for this class of wallets:

1. The following canonical phrase is defined: `DO NOT EVER SIGN THIS TEXT WITH YOUR PRIVATE KEYS! IT IS ONLY USED FOR DERIVATION OF LNURL-AUTH HASHING-KEY, DISCLOSING ITS SIGNATURE WILL COMPROMISE YOUR LNURL-AUTH IDENTITY AND MAY LEAD TO LOSS OF FUNDS!`.
2. `LN WALLET` obtains an `RFC6979` deterministic signature of `sha256(utf8ToBytes(canonical phrase))` using `secp256k1` with node private key.
3. `LN WALLET` defines `hashingKey` as `PrivateKey(sha256(obtained signature))`.
4. `SERVICE` domain name is extracted from auth `LNURL` and then service-specific `linkingPrivKey` is defined as `PrivateKey(hmacSha256(hashingKey, service domain name))`.

`LN WALLET` must make sure it is not possible to accidentally or automatically sign and hand out a signature of canonical phrase.