From aj at erisian.com.au  Fri Mar 18 06:03:17 2016
From: aj at erisian.com.au (Anthony Towns)
Date: Fri, 18 Mar 2016 16:03:17 +1000
Subject: [Lightning-dev] [BOLT RFC#1] Encryption spec
In-Reply-To: <87io0zndy1.fsf@rustcorp.com.au>
References: <87io0zndy1.fsf@rustcorp.com.au>
Message-ID: <20160318060317.GA21008@sapphire.erisian.com.au>

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