[Lightning-dev] [BOLT RFC#1] Encryption spec
aj at erisian.com.au
Fri Mar 18 06:03:17 UTC 2016
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 18.104.22.168 in ) 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:
> 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.
More information about the Lightning-dev