[Lightning-dev] [BOLT RFC#1] Encryption spec
rusty at rustcorp.com.au
Mon Mar 21 00:07:00 UTC 2016
Anthony Towns <aj at erisian.com.au> writes:
> 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 184.108.40.206 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.
The intention is that you'd do any upgrade by adding a second key, and
increasing the `length` field to cover it (say, to 66). If either side
sends a 33-byte initial packet, they've not ugpraded (whether you hang
up at this point or continue is up to you); if both send >= 66 bytes,
you use the second value instead.
I don't see what manipulating the length does?
PS. I should add an "Extensions" section to each BOLT...
>  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
More information about the Lightning-dev