From 529c7cddb7f313c4c4043d6b918fa69eb73761cf Mon Sep 17 00:00:00 2001 From: Jonas Schnelli Date: Wed, 13 Jul 2016 13:09:24 +0200 Subject: [BIP151] Switch from plain HMAC_SHA512 KDF to HKDF --- bip-0151.mediawiki | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) (limited to 'bip-0151.mediawiki') diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 18d3901..cc79712 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -36,17 +36,22 @@ Encryption initialization must happen before sending any other messages to the r === Symmetric Encryption Cipher Keys === -The symmetric encryption cipher keys will be calculated with ECDH by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be calculated with HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). +The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: -K_1 must be the left 32bytes of the HMAC_SHA512 hash. +1. HKDF extraction +PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type). -K_2 must be the right 32bytes of the HMAC_SHA512 hash. +2. Derive Key1 +K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32) -It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks. +3. Derive Key2 +K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32) + +It is important to include the cipher-type into the symmetric cipher key derivation to avoid weak-cipher-attacks. === Session ID === -Both sides must also calculate the 256bit session-id using HMAC_SHA256(key=ecdh_secret,msg="session id"). The session-id can be used for linking the encryption-session to an identity check. +Both sides must also calculate the 256bit session-id using SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32). The session-id can be used for linking the encryption-session to an identity check. === The encinit message type === @@ -69,19 +74,19 @@ Possible symmetric key ciphers types === ChaCha20-Poly1305 Cipher Suite === -ChaCha20 is a stream cipher designed by Daniel Bernstein [2]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, +ChaCha20 is a stream cipher designed by Daniel Bernstein [3]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded. -Poly1305, also by Daniel Bernstein [3], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use +Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. -The chacha20-poly1305@openssh.com specified and defined by openssh [4] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [5], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. +The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. -Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304 [5]. +Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. === The encack message type === @@ -164,10 +169,11 @@ This proposal is backward compatible. Non-supporting peers will ignore the