From rusty at rustcorp.com.au Tue Jun 28 02:43:09 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 28 Jun 2016 12:13:09 +0930 Subject: [Lightning-dev] [BOLT RFC#1] Encryption spec In-Reply-To: <1466941991.2812.8.camel@ultimatestunts.nl> References: <87io0zndy1.fsf@rustcorp.com.au> <1466941991.2812.8.camel@ultimatestunts.nl> Message-ID: <87furyc9tu.fsf@rustcorp.com.au> CJP 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.