On 4 Aug 2015, at 00:32 , Ian Goldberg iang@cs.uwaterloo.ca wrote:
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).
In common usage, "50% + 1" means floor(50% + 1). But I agree this should be clarified.
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.)
Let's follow the pattern used by other hashes in the torspec and rendspec, which is to include an uppercase string of full English words, separated by spaces, at the start of (almost all?) hashes.
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.
Unless there's a good reason not to include the values, using both the date and the previous random value should prevent replay-like attacks.
Regards
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7