[Lightning-dev] [BOLT RFC#1] Encryption spec

Anthony Towns 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 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:


> 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.


[0] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf

More information about the Lightning-dev mailing list