Commit Graph

6 Commits

Author SHA1 Message Date
Rusty Russell 42cf0ef543 peer: do logging before crypto is on.
We create a logging object when we connect, then carry it through.  If
it comes from the database, we just use the peerid as the log prefix.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-31 16:06:31 +09:30
Rusty Russell 7709eb9b4a protocol: use separate ack packet.
It's a data-leak to send ack before we have verified identity of peer.
Plus, we can't send it until we know which peer it is, anyway!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 14:23:46 +09:30
Rusty Russell 45a6f81c3c protocol: remove ack fields.
As per lightning-rfc commit 8ee09e749990a11fa53bea03d5961cfde4be4616,
we remove the acks from the protocol now they're no longer needed (and
all the infrastructure).

We also place the commit number in the commit_info where it logically
belongs, removing it from the peer struct.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-26 15:25:24 +09:30
Rusty Russell 0f35441a29 protocol: move `ack` out of header into specific packets.
This reflects the BOLT #1/#2 protocol change, as suggeted by Pierre.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-04-11 16:31:43 +09:30
Rusty Russell afedf0e8ac cryptopkt: implement ack callbacks.
For the change to asynchronous updates as specified by BOLT #2, we
need to know when the other side acknowledged a packet.  This creates
a simple callback mechanism for it.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-03-24 12:03:44 +10:30
Rusty Russell 74f294e36c daemon: encrypted communication (version 3)
After useful feedback from Anthony Towns and Mats Jerratsch (of
thunder.network fame), this is the third version of inter-node crypto.

1) First, each side sends a 33-byte session pubkey.  This is a
   bitcoin-style compressed EC key, unique for each session.
  
2) ECDH is used to derive a shared secret.  From this we generate
   the following transmission encoding parameters for each side:
   Session AES-128 key: SHA256(shared-secret || my-sessionpubkey || 0)
   Session HMAC key: SHA256(shared-secret || my-sessionpubkey || 1)
   IV for AES: SHA256(shared-secret || my-sessionpubkey || 2)

3) All packets from then on are encrypted of form:
	/* HMAC, covering totlen and data */
	struct sha256 hmac;
	/* Total data transmitted (including this). */
	le64 totlen;
	/* Encrypted contents, rounded up to 16 byte boundary. */
	u8 data[];

4) The first packet is an Authenticate protobuf, containing this node's
   pubkey, and a bitcoin-style EC signature of the other side's session
   pubkey.

5) Unknown protobuf fields are handled in the protocol as follows
   (including in the initial Authenticate packet):

   1) Odd numbered fields are optional, and backwards compatible.
   2) Even numbered fields are required; abort if you get one.

Currently both sides just send an error packet "hello" after the
handshake, and make sure they receive the same.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-22 06:41:48 +10:30