From rusty at rustcorp.com.au Tue Oct 27 19:44:07 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 28 Oct 2015 06:14:07 +1030 Subject: [Lightning-dev] [PATCH v3] daemon: encrypted communication (version 3) In-Reply-To: References: <87twpibc7m.fsf@rustcorp.com.au> Message-ID: <87fv0ww0zc.fsf@rustcorp.com.au> Pierre writes: > A few more remarks: > >> 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) > I suppose we use only the first 16 bytes for aes_key and aes_iv ? Yes, indeed... >> 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[]; > Looking at your code it seems totlen is actually the size of the > unencrypted serialized protobuf message, not the total data > transmitted right ? Yeah, bad wording. "data" here doesn't count the header, just the contents. > If so, the comment is a bit misleading, and why > make totlen include the length of itself since it doesn't define the > encrypted message boundaries anyway ? We need to know how much padding to ignore. > Also, why encode the length on 64 bits rather than 32 bits ? So it never wraps. Cheers, Rusty.