Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

[Ian Goldberg <iang@xxxxxxxxxxxxxxx>]

Nice work!  A couple of minor comments:

On Mon, Aug 03, 2015 at 05:03:38PM +0300, George Kadianakis wrote:
>    A shared random document requires 50% + 1 authority signatures to be
>    considered valid. As this proposal is being written, there are 9
>    authorities thus we would need 5.

Careful there.  "50% + 1" of 9 is 5.5, so you'd need 6.  I assume you
*want* to only require 5, so you should rephrase "50% + 1" (it appears a
couple of times in the document).

> 3.3.1. Shared Randomness Calculation [SRCALC]
> 
>    An authority that wants to derive the shared random value V, should use the
>    appropriate reveal values for that time period and calculate V as follows:
> 
>       V = H(ID_a | R_a | ID_b | R_b | ...)
> 
>    where the ID_k value is the identity fingerprint of directory authority k
>    and R_k is its corresponding reveal value of that authority for the current
>    period. H is sha256 for protocol version 1.

How do you determine what order to include the IDs and Rs in the above
hash?  Also, since the number of votes is not necessarily constant, I'm
slightly worried about length-extension issues unless you stick an
encoding of the number of votes at the beginning of the input to the hash.
(And while you're at it, start with a string identifying the protocol
and version as well.)

>    XXX Should the hashing here include more elements? Like the previous random
>        value for chaining? Or the current date? See how the NIST beacon does it
>        in case we can steal some additional RNG security properties:
>                http://hackaday.com/2014/12/19/nist-randomness-beacon/

Yes, you should definitely include *something* to break the symmetry
among days.

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