mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

[BIP151] Switch from plain HMAC_SHA512 KDF to HKDF

Browse Source
This commit is contained in:
Jonas Schnelli 2016-07-13 13:09:24 +02:00
parent 5ddea46bce
commit 529c7cddb7
No known key found for this signature in database
GPG Key ID: 29D4BCB6416F53EC
1 changed files with 19 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
bip-0151.mediawiki
View File

@ -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 <code>HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key")</code>.
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:
<code>K_1</code> must be the left 32bytes of the <code>HMAC_SHA512</code> hash.
1. HKDF extraction
<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type)</code>.
<code>K_2</code> must be the right 32bytes of the <code>HMAC_SHA512</code> hash.
2. Derive Key1
<code>K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)</code>
It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks.
3. Derive Key2
<code>K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32)</code>
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 <code>HMAC_SHA256(key=ecdh_secret,msg="session id")</code>. 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 <code>SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32)</code>. The session-id can be used for linking the encryption-session to an identity check.
=== The <code>encinit</code> 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.
<code>K_1</code> must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size.
<code>K_2</code> 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 <code>encack</code> message type ===
@ -164,10 +169,11 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code
== References ==
* [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
* [2] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
* [3] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
* [4] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
* [5] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
* [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869
* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
* [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
== Acknowledgements ==
* Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.