[tor-commits] [torspec/master] prop224: hash raw random bytes before use

[nickm@xxxxxxxxxxxxxx]

commit 93f47f4f4e7614d4b3debfe9b5f3a22bfe5d64b1
Author: teor (Tim Wilson-Brown) <teor2345@xxxxxxxxx>
Date:   Fri Nov 20 11:43:51 2015 +1100

    prop224: hash raw random bytes before use
    
    Exposing raw random bytes from a PRNG has broken Dual EC:
    http://projectbullrun.org/dual-ec/ext-rand.html
    
    Based on ioerror's feedback on prop250, make similar changes:
    https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html
---
 proposals/224-rend-spec-ng.txt |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index ad0947c..2aeb05b 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -865,10 +865,13 @@ Status: Draft
 
    The encrypted data has the format:
 
-       SALT       (random bytes from above)       [16 bytes]
+       H(SALT)    H(random bytes from above)      [16 bytes]
        ENCRYPTED  The plaintext encrypted with S  [variable]
        MAC        MAC of both above fields        [32 bytes]
 
+   (We hash salt so that we don't leak the raw bytes returned by a PRNG
+   to the network. See [RANDOM-REFS].)
+
    The encryption format is ENCRYPTED =
                STREAM(SECRET_IV,SECRET_KEY) xor Plaintext
 
@@ -1479,7 +1482,9 @@ Status: Draft
         Pubkey    [32 bytes]
         Signature [64 bytes]
 
-   Nonce is a random value. Pubkey is the public key that will be used
+   Nonce is a random value. (Noncen should be derived from hashed PRNG
+   output, so that we don't leak the raw bytes returned by a PRNG to the
+   network. See [RANDOM-REFS].) Pubkey is the public key that will be used
    to authenticate. [TODO: should this be an identifier for the public
    key instead?]  Signature is the signature, using Ed25519, of:
 
@@ -1522,7 +1527,9 @@ Status: Draft
    by the client. The client SHOULD choose a new rendezvous cookie for
    each new connection attempt. If the rendezvous cookie is already in
    use on an existing circuit, the rendezvous point should reject it and
-   destroy the circuit.
+   destroy the circuit. RENDEZVOUS_COOKIE should be derived using hashed
+   PRNG output, so that we don't leak the raw bytes returned by a PRNG
+   to the network. See [RANDOM-REFS].
 
    Upon receiving a ESTABLISH_RENDEZVOUS cell, the rendezvous point
    associates the cookie with the circuit on which it was sent. It
@@ -1639,6 +1646,9 @@ References:
         J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and
         Bo-Yin Yang. http://cr.yp.to/papers.html#ed25519
 
+[RANDOM-REFS]:
+        http://projectbullrun.org/dual-ec/ext-rand.html
+        https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html
 
 Appendix A. Signature scheme with key blinding [KEYBLIND]
 



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