From rusty at rustcorp.com.au  Mon Mar 21 00:07:00 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 21 Mar 2016 10:37:00 +1030
Subject: [Lightning-dev] [BOLT RFC#1] Encryption spec
In-Reply-To: <20160318060317.GA21008@sapphire.erisian.com.au>
References: <87io0zndy1.fsf@rustcorp.com.au>
	<20160318060317.GA21008@sapphire.erisian.com.au>
Message-ID: <8737rkn17f.fsf@rustcorp.com.au>

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

Thanks!

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

Cheers,
Rusty.
PS.  I should add an "Extensions" section to each BOLT...







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