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

[teor]

> On 4 Aug 2015, at 22:00 , George Kadianakis <desnacked at riseup.net> wrote:
> 
> Hello,
> 
> and thanks for the comments.
> 
> I uploaded a new version of the proposal that addresses some of your feedback.
> 
> You can find it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=rng-draft-v4-asn

Thanks for making these changes.

>>> 4.1.3. Shared Random value
>>> 
>>> Authorities include a shared random value in their votes using the following
>>> encoding for the previous and current value respectively:
>>> 
>>> "shared-rand-previous-value" SP value NL
>>> "shared-rand-current-value" SP value NL
>>> 
>>> where "value" is the actual shared random value. It's computed as specified
>>> in the section [SRCALC].
>> 
>> Is "value" encoded using base64-encode as well?
>> 
> 
> Hm, we should define this.
> 
> BTW, do we prefer base64 or base32? I would vote for base32 for readability.
> 
> Also, the few extra bytes can't be that much overhead.

I prefer base32 for readability.
(Do we specify the base32 variant somewhere else? In the torspec?)

In a text-based format, with signatures and everything, the length of the commit and reveal values isn't particularly significant. In base64, a 256 bit value is 43 characters long, and in base32, it's 52 characters long. The difference is 9 characters, or 17%.

The microdescriptor consensus size is most significant, as it will be transferred many times. (The SR document will only be transferred between the authorities, so its size is much less of an issue.)

The size of the additions to the microdescriptor consensus is:
> "shared-rand-previous-value" SP value NL
> "shared-rand-current-value" SP value NL

26 + 1 + v + 1 +
25 + 1 + v + 1
= 55 + 2v

Which is:
141 characters in base64.
159 characters in base32.
A difference of 18 characters, or 11%.

A recent microdescriptor consensus was 1.25MB.
18 characters is far less than the size of a single microdescriptor consensus entry, and about a thousandth of a percent of the entire consensus size.
So the difference is irrelevant, AFAICT.

>>> 3.7. Shared Randomness Disaster Recovery [SRDISASTER]
>>> 
>>> If the consensus at 12:00UTC fails to be created, then there will be no new
>>> shared random value for the day.
>>> 
>>> Directory authorities should keep including the previous shared random
>>> values in the consensus till the next 12:00UTC commit-and-reveal session.
>>> The time period needs to be updated to reflect the current time period even
>>> if the random value stays the same.
>>> 
>>> Clients should keep on using this shared random values.
>> 
>> (If the timestamp is updated, clients wouldn't even know that the protocol had failed, even if they downloaded the shared randomness document, unless they specifically checked for failure.)
>> 
>> We could instead run an instance of the hash with an empty set of reveals like so:
>> 
>> V = H("TOR SHARED RANDOMNESS PROTOCOL VERSION 1" | DATE | PREVIOUS_SHARED_RANDOMNESS_VALUE)
>> 
>> This would gracefully degrade the protocol, and provide a predictable but different value each day, based on the previous value and the date, very much like the current HSDir hash ring.
>> 
>> But does this gain us anything?
>> (The HSDirs would at least move each day, albeit predictably. We might want this property.)
>> 
> 
> I think the result here will be the same.
> 
> However, I agree that making it hard to detect failure is a bad idea. We should
> think of how to make this more obvious.

We could add a shared random status line to the consensus (and SR doc) giving the status of the latest completed shared random round - success, failure, bootstrap 0, or bootstrap 1.

The expected state transitions would be:

(start) -> bootstrap 0 -> bootstrap 1 -> success -> success …
(failure in any state) -> failure -> success -> success …

This would allow clients to determine how reliable the shared randomness is at any point in time.

Tim (teor)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150804/1aa044e5/attachment-0001.sig>