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

Rusty Russell rusty at rustcorp.com.au
Tue Jun 28 02:43:09 UTC 2016


CJP <cjp at ultimatestunts.nl> writes:
> Hi,
>
> I'm about to start implementing an encryption layer for Amiko Pay, and
> since there already is a BOLT for encryption, I thought I might as well
> see if I can use it. Now that I've read it[1], I have some questions.

Good!

> But first, let me comment that, in general, I like the general design of
> the encryption layer. It's generic and simple, making it easy to
> analyze, which is A Good Thing.
>
> My first question is: would it be possible / useful for a node to use
> different public keys for different links? I guess it is possible: the
> node that's establishing the connection knows what link it tries to
> connect, so it can already send out an authenticate message. The other
> node initially doesn't know what link the new connection belongs to,
> but, after receiving the authenticate message, it knows, so it can
> select its own corresponding key and reply with its own authenticate
> message. Then again, I'm not sure if this is very useful. Using
> different keys could be good for privacy (not revealing that both links
> go to the same node), but a node that listens for multiple links on the
> same network location (e.g. host:port in TCP) already shows to its peers
> that both links have a shared identity. The key used for authentication
> could be different from keys used for other things, like routing
> addresses or output addresses of microtransaction channels, maybe linked
> in master/slave key configurations (one key signs the other). Maybe
> there still is a deniability problem (your peer reveals data and you
> want to say 'it wasn't me') but I'm not sure that can be solved.

One can imagine a front end cache which points to different backends
depending on who the incoming connection is for.  (The classic http
multihost problem).

This is one reason packets are extensible, if we turn out to want this
in future.

> I was wondering to what degree communication truly looks like random
> data, or can be distinguished from it. I guess that the very first 4
> bytes, usually being the little-endian value 33, already gives away that
> this protocol is being used. Furthermore, timing analysis could reveal
> the size of messages being sent, possibly revealing information about
> what is being done with the payload protocol inside the encryption
> layer. Is there a way to protect against that? You might want to append
> unused data to messages to make them fixed size (or at least multiples
> of a fixed size), or random size, but that reduces bandwidth efficiency,
> and the required amount of padding depends on the payload protocol.

The lengths (after that first packet) are encrypted.  We can add ping
and pong messages for dummies later if we want to, but solving traffic
analysis is not really a priority for now (AFAICT a bottomless well).

> How is the authenticate message distinguished from other messages? I
> don't see something like a message type ID. Is it simply that the first
> message in a session is ALWAYS an authenticate message, and other
> messages are NEVER an authenticate message?

It's a protobuf, like all messages.  We should probably mention that :)

> Right now, the description of session_sig in the authenticate message
> says: "session_sig is the signature of the SHA256 of SHA256 of the
> receivers node_id, using the secret key corresponding to the sender's
> node_id". I am not sure how that is useful. More importantly, I don't
> understand what stops someone from performing a MITM attack. Shouldn't
> you include something like a signature of your sessionpubkey, signed
> with your node_id key?

Yes :(  It should sign the sessionpubkey of course.  I'll fix...

> Assuming that a MITM attacker can guess the boundaries of messages, what
> stops him/her from duplicating messages, or removing messages? Is a
> certain state preserved between encryption/authentication of different
> messages?

The nonce increments:

 Nonces are 64-bit little-endian numbers, which MUST begin at 0 and
 MUST be incremented after each encryption (ie. twice per message), such
 that headers are encrypted with even nonces and the message bodies
 encrypted with odd nonces.

> What is the meaning of the ack field in the authenticate message? The
> number of non-authenticate messages before an authenticate message *in a
> session* is always zero, isn't it?

It's to resume existing sessions.  It's underspecified because I had not
implemented that (and my protocol test uses the count of commitments
received, which turns out to be superior).

> I see it's the number of messages
> *received and processed*. Since, to my knowledge, data streams in both
> directions are asynchronous, that could be a non-deterministic value,
> right? What should a receiving node check about the ack value? If it
> can't check anything, then what is the use of the value? Is this about
> message re-transmission across multiple sessions? In that case, please
> think about wrap-around behavior. I'm not sure a 64-bit counter will
> ever wrap around, but we should make sure the first time it happens
> won't be "in the field".

64 bit counters won't wrap during my watch :)

Thanks,
Rusty.


More information about the Lightning-dev mailing list