[tor-dev] Needs Code Review: Shared Randomness Generation for Tor

[Tim Wilson-Brown - teor]

> On 13 Jan 2016, at 20:02, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
>> 
>>> On 13 Jan 2016, at 01:46, George Kadianakis <desnacked at riseup.net> wrote:
>>> 
>>> ...
>>> For what it's worth, we expect this code to run for a long time before the
>>> shared random values generated by the authorities are used for anything
>>> (e.g. HSDir scrambling).
>> 
>> I've seen you talk about using chutney for shared randomness generation.
>> Can you open a ticket with a branch for the chutney SR template, so people can use it for testing?
>> (And then we can merge it into chutney master about the same time this code goes into tor master.)
> 
> We've done extensive testing already with chutney. I don't think we need
> a specific SR template since this is part of the voting system which
> ultimately put the SR values in the consensus.
> 
> I mostly used the "hs" template for this and sometimes used a variation
> of it with 9 dirauths instead of 3.
> 
>> 
>> There's a make target, "test-network-all", that runs a series of chutney tests.
>> Each of these tests finish in around 35 seconds.
>> 
>> Can we get a SR chutney template to finish in around that time?
>> (With 10 second voting periods?)
>> What is the minimum number of voting periods that shared randomness requires?
>> (I understand the standard setting is 24, 12 for the commit, and 12 for the reveal.)
> 
> For now, that won't be possible :S, the number of rounds per phase (12
> commits and 12 reveals) are hardcoded so no torrc options to change
> them. We could make it that in TestingNetwork, this is divided by 4
> having 3 and 3 but then we are at 60 seconds so :S... Do you think even
> just that would be useful?

If the minimum number of rounds per phase is 3, then let's set it at 3 in test networks.
(But leave it as a configurable, test-network-only parameter, like the many other test network parameters.)
60 seconds is better than 240 seconds, and it means the tests are more likely to get run.

> On the other hand, a very very useful test would be to have a way to
> kill/spawn/kill/spawn dirauth to simulate reboots or a way to make them
> miss voting periods. That doesn't sound to me that crazy difficult to
> achieve with chutney and in that case we could have an epic SR template
> that imposes conditions on dirauth lifetime.

I think this is one of those future features that would require a rewrite of chutney, or at least substantially more code.
I agree it would be useful.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160113/e29bee22/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160113/e29bee22/attachment.sig>