diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki
index 18d39017..cc797121 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