Hello there,
we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review.
You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_... and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1
Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec.
Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}.
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).
Cheers!
On 13 Jan 2016, at 01:46, George Kadianakis desnacked@riseup.net wrote:
Hello there,
we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review.
You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_... and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1
Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec.
Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}.
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.)
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.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
On 13 Jan 2016, at 01:46, George Kadianakis desnacked@riseup.net wrote:
Hello there,
we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review.
You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_... and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1
Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec.
Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}.
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?
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.
Thanks! David
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 13 Jan 2016, at 20:02, David Goulet dgoulet@ev0ke.net wrote:
On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
On 13 Jan 2016, at 01:46, George Kadianakis desnacked@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
-
David Goulet -
George Kadianakis -
Tim Wilson-Brown - teor