📅 Original date posted:2016-03-18
📝 Original message:
On Mon, Mar 07, 2016 at 02:21:02PM +1030, Rusty Russell wrote:
> ### Derivation of the Shared Secret and Encryption Keys ###
> Once a node has received the initial handshake, it can derive the
> shared secret using the received `sessionpubkey` point and its own
> `sessionsecretkey` scalar using EC Diffie-Hellman.
I think this should be expanded -- I'm assuming the sessionsecretkey is
calculated as per libsecp256k1, as:
(x,y) = y.public*x.secret = x.public*y.secret = g*(x.secret*y.secret)
sha256( (2 + y%2) || x )
This is different to the NIST specification (see 5.7.1.2 in [0]) which
just uses the x coordinate of the point directly, ignoring y and not
(necessarily) hashing it.
I've added some wording for this for your consideration:
https://github.com/rustyrussell/lightning/pull/1
> While multiple choices are possible for public-key cryptography, the
> bitcoin protocol already relies on the secp256k1 elliptic curve, so
> reusing it here avoids additional dependencies.
Hmm, if secp256k1 breaks and gets deprecated, that would be a backwards
incompatible change. You could handle this with the protocol as described
by incrementing the high byte of "length" in the first message; old
clients would see that as an invalid length, >16M, and refuse the
connection; new clients could just treat it as a version byte.
Cheers,
aj
[0] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:45:53
in reply to nevent1q…4uth
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:45:53Event JSON
{
"id": "39d890d6dd7eee09349f2e0debbac3e07b9d932e11fcd374685020c49da7415c",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314753,
"kind": 1,
"tags": [
[
"e",
"dcbe6f3037094641d72048a8ba50dc00d7f502d13836784cf70fabe52144a95e",
"",
"root"
],
[
"e",
"fd7fc4cf77614e1ec652862e6f451aea0e2077d6cc3ef56bf8f87607aec8bb87",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-03-18\n📝 Original message:\nOn Mon, Mar 07, 2016 at 02:21:02PM +1030, Rusty Russell wrote:\n\u003e ### Derivation of the Shared Secret and Encryption Keys ###\n\u003e Once a node has received the initial handshake, it can derive the\n\u003e shared secret using the received `sessionpubkey` point and its own\n\u003e `sessionsecretkey` scalar using EC Diffie-Hellman.\n\nI think this should be expanded -- I'm assuming the sessionsecretkey is\ncalculated as per libsecp256k1, as:\n\n (x,y) = y.public*x.secret = x.public*y.secret = g*(x.secret*y.secret)\n sha256( (2 + y%2) || x )\n\nThis is different to the NIST specification (see 5.7.1.2 in [0]) which\njust uses the x coordinate of the point directly, ignoring y and not\n(necessarily) hashing it.\n\nI've added some wording for this for your consideration:\n\n https://github.com/rustyrussell/lightning/pull/1\n\n\u003e While multiple choices are possible for public-key cryptography, the\n\u003e bitcoin protocol already relies on the secp256k1 elliptic curve, so\n\u003e reusing it here avoids additional dependencies.\n\nHmm, if secp256k1 breaks and gets deprecated, that would be a backwards\nincompatible change. You could handle this with the protocol as described\nby incrementing the high byte of \"length\" in the first message; old\nclients would see that as an invalid length, \u003e16M, and refuse the\nconnection; new clients could just treat it as a version byte.\n\nCheers,\naj\n\n[0] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf",
"sig": "13228af0e588b08cbff3c92452042a4bf851512d5b96792ea2c0daf09ae92aee23c713c9cc233555f2270042dca4ee458fa63dcd255d05693685c107336144b0"
}