[tor-commits] [torspec/master] Adjust Krawczyk's construction to be RFC5869.

[nickm@xxxxxxxxxxxxxx]

commit 35d872981166ef4b1fca2fe9766de530346e2873
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Mon Dec 3 10:30:05 2012 -0500

    Adjust Krawczyk's construction to be RFC5869.
---
 proposals/216-ntor-handshake.txt |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt
index c6c6579..2ee9b14 100644
--- a/proposals/216-ntor-handshake.txt
+++ b/proposals/216-ntor-handshake.txt
@@ -103,13 +103,13 @@ Key expansion:
 
        where K0==g^xy, and K is divvied up into Df, Db, Kf, and Kb portions.
 
-  Instead, let's have it be
+  Instead, let's have it be HKDF-SHA256 as defined in RFC5869:
 
-       K = K_0 | K_1 | K_2 | K_3 | ...
+       K = K_1 | K_2 | K_3 | ...
 
-       Where K_0     = H(m_expand | INT8(i) , KEY_SEED )
+       Where K_1     = H(m_expand | INT8(1) , KEY_SEED )
          and K_(i+1) = H(K_i | m_expand | INT8(i) , KEY_SEED )
-         and m_expend is an arbitrarily chosen value,
+         and m_expand is an arbitrarily chosen value,
          and INT8(i) is a octet with the value "i".
 
   Ian says this is due to a construction from Krawczyk at
@@ -117,6 +117,9 @@ Key expansion:
 
   Let m_expand be PROTOID | ":key_expand"
 
+  In RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand,
+  salt == t_key, and IKM == secret_input.
+
 Performance notes:
 
   In Tor's current circuit creation handshake, the client does:



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits