Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Auth protocol description, add example values, fix bug. #249

Open
wants to merge 2 commits into
base: luds
Choose a base branch
from
Open

Update Auth protocol description, add example values, fix bug. #249

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ddc7b6d
Update Auth protocol description, add example values, fix bug.
michaelWuensch Nov 26, 2023
26f2c4b
Added missing k1 that made example useless
michaelWuensch Nov 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions 04.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,10 @@ Later, once `LN SERVICE` receives a call at the specified `LNURL-auth` handler,

However, the second goal is not reachable in practice because there exist different formats of seeds which can't be transferred across all existing wallets. As such, a practical approach is to have recommended ways to derive `linkingKey` for different wallet types.

Please refer to the following LUDs for more details:
[LUD-05](05.md): BIP32-based seed generation for auth protocol.
[LUD-13](13.md): signMessage-based seed generation for auth protocol.


## Signature check examples

Expand Down
29 changes: 26 additions & 3 deletions 13.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,31 @@ Here we define a canonical phrase to be signed, and from that we will derive the
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))`.
2. `LN WALLET` obtains an `RFC6979` deterministic signature of `sha256(sha256(utf8ToBytes(canonical phrase)))` using `secp256k1` with node private key.
3. `LN WALLET` defines `hashingKey` as `sha256(obtained signature)`.
4. `SERVICE` domain name is extracted from auth `LNURL` and then service-specific `linkingPrivKey` is defined as `hmacSha256(hashingKey, utf8ToBytes(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.

### Example
To simplify the implementation, here is an example with all relevant intermediate steps, starting with the signed canonical phrase (Step 3 of this document):

**k1:**
a7830ce0d70e447ff888a72253cb3b564d52362a0aba25c9bd74c36f54d5431e
**domain:**
lightninglogin.live
**obtained signature (of canonical phrase):**
d99tpq15iyafmpsi5s4a43dmbwknprjb9i378xj4acki7akefzwk6ygoefjqqy7xck6njam5shcrgzh697wjhsaxjko7b9wkto4juezw

**hashingKey:**
0bdf5689da0db751c3f93366093f55a007c814f352e1f8f2a128c864e6f7fa41
**linkingPrivKey:**
9628eaef95f5c72fc4bcbfc1d3fe46805484aa1ee0d9cc219d342ef1ee926b47

And further steps described in Lud 4:
**linkingKey:**
026c29c00976a94dc59f8ee33b12709d549e9d6ddc58744cdfcf7eda5af18da853
**signed_K1:**
bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e603934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375
**signed_K1_DER_encoded:**
3045022100bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e6022003934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375