The #Bitcoin #Lightning Spec Part 8/8: Encrypted and Authenticated Transport
This is another Olaoluwa Osuntokun find: the Noise Protocol; in particular, we use Noise_XK for the handshake between nodes. The noise protocol leaves the choice of crypto primitives to the user, and for us it’s:
- DH function: libsecp256’s ECDH function.
- Cipher function: ChaCha20-Poly1305 (IETF variant).
- Hash function: SHA-256.
But you don’t even have to read the Noise_XK spec; the exact steps for each side during each of the three “acts” is spelled out in detail in the document. I’ve implemented it from that, and with a few updates for clarity and a minor change for consistency, the test vectors agree across Laolu’s implementation in lnd, Fabrice’s in Eclair and mine in c-lightning.
The framing used is a 2-byte encrypted message length, followed by a 16-byte MAC, followed by the encrypted message, followed by another 16-byte MAC. This format avoids problems with huge messages, and also length underruns. We use this framing directly for the upper layers, so we are restricted to 64k for lightning messages which has not been a problem so far; fragmentation is fairly trivial to implement if we need it later.
My only complaint about this part of the spec is that despite dividing into three acts, it lacks drama. If I had written it, I don’t think I could have avoided sentences like “The recipient MUST exit stage left” and “At this point, our hero has to prove her worth by singlehandedly computing the ECDH”. Not sure how well such a pull request would be received, though…
