commit 35d872981166ef4b1fca2fe9766de530346e2873 Author: Nick Mathewson <nickm@torproject.org> 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: