Merge pull request #430 from jonasschnelli/2017/08/bip151_rekey

[bip151] slightly increase robustness of the re-keying

bip-0151.mediawiki

@@ -39,7 +39,7 @@ Encryption initialization must happen before sending any other messages to the r
 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:
 
 1. HKDF extraction
-<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type)</code>.
+<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type)</code>.
 
 2. Derive Key1
 <code>K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)</code>
@@ -148,7 +148,7 @@ If more data is present, another message must be deserialized. There is no expli
 
 A responding peer can inform the requesting peer over a re-keying with a <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''.
 
-The new symmetric cipher key will be calculated by <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
+The new symmetric cipher key will be calculated by <code>SHA256(SHA256(session_id || old_symmetric_cipher_key))</code>.
 
 Re-Keying interval is a peer policy with a minimum timespan of 10 seconds.