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