lightning

466 Commits

55 Branches

107 Tags

38 MiB

Tree: cc16f46621

Commit Graph

Author	SHA1	Message	Date
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>	9 years ago

Author

SHA1

Message

Date

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>

9 years ago

1 Commits (cc16f4662109590daf9f42d6bde34a048775c4f9)