Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

> On 8 Nov 2015, at 05:39, s7r wrote: > > For all versions of the proposal, regardless if we use the conflict > code or not, I think we should require authorities to participate for > at least for 3 rounds of the reveal phase, otherwise not participate > in the shared

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

On 06 Nov (15:35:50), George Kadianakis wrote: > George Kadianakis writes: > > > s7r writes: > > > >> Hello, > >> > >> > >> > >> 4.1.1. Computing commitments and reveals [COMMITREVEAL] > >> "The value REVEAL is computed as follows: > >> > >> REVEAL

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

George Kadianakis writes: > s7r writes: > >> Hello, >> >> >> >> 4.1.1. Computing commitments and reveals [COMMITREVEAL] >> "The value REVEAL is computed as follows: >> >> REVEAL = base64-encode( TIMESTAMP || RN )" >> >> * Maybe it is useful to also

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 asn, Is it possible to add a field called 'NOTARY' in the COMMIT and REVEAL values where we include the SR pubkey + certificates and everything we need so that we can validate each COMMIT / REVEAL value and tie it to the identity of a directory

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Epic work. I agree that the code enforcing commit majority was not making a difference in the partition attack. I also agree that the partition attack is (almost) useless, expensive and very noisy. An attacker can get the same result if,

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

> On 31 Oct 2015, at 01:07, George Kadianakis wrote: > > Jesse V writes: > >> David, >> >> I'm in the midst of reworking my OnioNS design around prop250 (and the >> security >> analysis therein) and as far as I can tell these changes make sense.

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

Jesse V writes: > David, > > I'm in the midst of reworking my OnioNS design around prop250 (and the > security > analysis therein) and as far as I can tell these changes make sense. I like > the > 00:00 -> 24:00 change as it's more intuitive as you said. I was at first

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

teor writes: >> On 29 Oct 2015, at 05:26, David Goulet wrote: >> >> Finally, we would like your opinion also on if we should keep the >> conflict mechanism or not?. Since those partition attacks are basically >> dumb, do not achive much result for an

[tor-dev] Update of prop#250: Random Number Generation During Tor Voting

Hello Tor-Dev! We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :). Attached is the new version that we've been working on. We

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

David, I'm in the midst of reworking my OnioNS design around prop250 (and the security analysis therein) and as far as I can tell these changes make sense. I like the 00:00 -> 24:00 change as it's more intuitive as you said. I was at first very concerned that you removed the majority

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

> On 29 Oct 2015, at 05:26, David Goulet wrote: > > Finally, we would like your opinion also on if we should keep the > conflict mechanism or not?. Since those partition attacks are basically > dumb, do not achive much result for an attacker and it's at a high cost > of