From cjp at ultimatestunts.nl  Sun Jun 26 11:53:11 2016
From: cjp at ultimatestunts.nl (CJP)
Date: Sun, 26 Jun 2016 13:53:11 +0200
Subject: [Lightning-dev] [BOLT RFC#1] Encryption spec
In-Reply-To: <87io0zndy1.fsf@rustcorp.com.au>
References: <87io0zndy1.fsf@rustcorp.com.au>
Message-ID: <1466941991.2812.8.camel@ultimatestunts.nl>

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.

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.

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.

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?

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?

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?

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

thanks,
CJP

[1]
https://github.com/rustyrussell/lightning-rfc/blob/master/bolts/01-encryption.md