[tor-commits] [torspec/master] Prop262: s/shake128/shake256/

[nickm@xxxxxxxxxxxxxx]

commit 443606f0f60e98dbaab5ac4c9de4a046c06fc8a4
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Thu Dec 31 22:31:28 2015 -0500

    Prop262: s/shake128/shake256/
---
 proposals/262-rekey-circuits.txt |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/proposals/262-rekey-circuits.txt b/proposals/262-rekey-circuits.txt
index ca8ad01..e7c66f8 100644
--- a/proposals/262-rekey-circuits.txt
+++ b/proposals/262-rekey-circuits.txt
@@ -30,10 +30,10 @@ Status: Open
         }
 
         const REKEY_METHOD_ACK = 0;
-        const REKEY_METHOD_SHAKE128_CLIENT = 1;
+        const REKEY_METHOD_SHAKE256_CLIENT = 1;
 
    This cell means "I am changing the key." The new key material will be
-   derived from SHAKE128 of the aez_key concatenated with the rekey_data
+   derived from SHAKE256 of the aez_key concatenated with the rekey_data
    field, to fill a new shake_output structure.  The client should set
    rekey_data at random.
 
@@ -69,8 +69,8 @@ Status: Open
 
    Each relay cipher must specify its own behavior in the presence of a
    REKEY cell of each type that it supports.  In general, the behavior
-   of method 1 ("shake128-client") is "regenerate keys as if we were
-   calling the original KDF after a CREATE handshake, using SHAKE128 on
+   of method 1 ("shake256-client") is "regenerate keys as if we were
+   calling the original KDF after a CREATE handshake, using SHAKE256 on
    our current static key material and on a 32-byte random input."
 
    The behavior of any unsupported REKEY method must be to close the

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