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

> George Kadianakis writes: > >> Hello there, >> > > Hello, > > I'm inlining the latest version of proposal250. > > It includes various improvements, like completely removing the need for an SR > doc (which will make implementation much much easier), and switching to >

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

George Kadianakis writes: > Hello there, > Hello, I'm inlining the latest version of proposal250. It includes various improvements, like completely removing the need for an SR doc (which will make implementation much much easier), and switching to signature-based

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I disagree. can you describe how exactly? What exactly can be gamed, if we use the protection described by me? It will provide the same security as directory authorities already have for voting about relays. It's true that ultimately anything can be

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

On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: > > > On 7 Sep 2015, at 23:36, David Goulet wrote: > > ... > > Please review it, mostly format of the state (before the SR document) > > has changed. As well as a new "conflict" line is added to the vote. > > … > > > > If

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

On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote: > On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: >> >> > On 7 Sep 2015, at 23:36, David Goulet wrote: >> > ... >> > Please review it, mostly format of the state (before the SR document) >> > has

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Sending the comments from #tor-dev here as well. This is related to the attack where exactly half of the directory authorities commit to some values, and the last directory authority can send different values to both camps, and have the

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

I'm not a big fan of automated systems that ban authorities as it may get false positives and it may be gamed and/or attacked. An alternative solution is to make the voting a two-step system: first you publish the sha256 hash of your vote, then a few minutes later you publish the actual vote.

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

> On 7 Sep 2015, at 23:36, David Goulet wrote: > ... > Please review it, mostly format of the state (before the SR document) > has changed. As well as a new "conflict" line is added to the vote. > … > If an authority sees two distinct commitments from an other authority in >

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

Hello! While working on the implementation of this proposal, we realized that it was much more complicated to add a new consensus flavor than we originally anticipated. nickm then suggested to NOT use this new flavor (shared random document) and instead change it to a persistent state on disk

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

Another implementation note on directory caching of the SR doc: I just noticed the following code in update_consensus_networkstatus_downloads(): for (i=0; i N_CONSENSUS_FLAVORS; ++i) { /* need some way to download unknown flavors if we are caching. */ This means that any new consensus

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

On 10 Aug 2015, at 23:07 , George Kadianakis desnac...@riseup.net wrote: teor teor2...@gmail.com writes: On 4 Aug 2015, at 22:00 , George Kadianakis desnac...@riseup.net wrote: Hello, snip 3.7. Shared Randomness Disaster Recovery [SRDISASTER] If the consensus at 12:00UTC fails

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

teor teor2...@gmail.com writes: Another implementation note on directory caching of the SR doc: I just noticed the following code in update_consensus_networkstatus_downloads(): for (i=0; i N_CONSENSUS_FLAVORS; ++i) { /* need some way to download unknown flavors if we are

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

On 12 Aug 2015, at 04:35 , George Kadianakis desnac...@riseup.net wrote: teor teor2...@gmail.com writes: Another implementation note on directory caching of the SR doc: I just noticed the following code in update_consensus_networkstatus_downloads(): for (i=0; i

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

teor teor2...@gmail.com writes: On 4 Aug 2015, at 00:03 , George Kadianakis desnac...@riseup.net wrote: … 3.1.2. Shared Random Document During Commitment Phase [SRDOCCOMMIT] … Hello, and thanks for the comments. I uploaded a new version of the proposal that addresses some of your

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

On 4 Aug 2015, at 22:00 , George Kadianakis desnac...@riseup.net wrote: XXX The number of active participants is dynamic as authorities leave and join the protocol. Since the number of active participants is dynamic , an attacker could trick some authorities believing there are N

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

On 4 Aug 2015, at 00:32 , Ian Goldberg i...@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

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

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

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

On 4 Aug 2015, at 00:03 , George Kadianakis desnac...@riseup.net wrote: … 3.1.2. Shared Random Document During Commitment Phase [SRDOCCOMMIT] … Also, an authority should not be able to register a commitment value for a different authority. Hence, an authority X should only vote and place