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

[David Goulet]

On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
> 
> > On 7 Sep 2015, at 23:36, David Goulet <dgoulet at ev0ke.net> 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
> > the same period, the authority is broken or evil: you include both, thereby
> > proving there is a conflict:
> > 
> > "shared-rand-conflict" SP identity SP commit1 SP commit2 NL
> > 
> > where "identity" is the hex-encoded commitment's authority fingerprint.
> > "commit1" is the previous commit that the authority had in its state and
> > "commit2" is the new received commit of the same period. Both commit values
> > are constructed as specified in section [COMMITENCODING].
> 
> 
> What if there are more than two conflicting commitments?
> Should they all be included?
> Is there a denial of service opportunity here, where an authority just keeps generating commitments to fill up the state files?

Hrm... that is a good point!

We could put in a maximum number of conflicts let's say 5 and add a
timestamp to it (meh...). Or when voting, we only add the latest per
"identity". I think the important part is just that "oh at this period,
we have a proof of conclict, wtf".

But tbh, I'm less and less confident about this because for example an
authority voting then rebooting immediately and then voting again will
trigger a conflict even though this is totally acceptable I think
(assuming the initial commit value was not saved in the state on disk).

I originally liked the idea of having a proof in the vote that a
conflict happened which could help us detect mis-behaving dirauth
(malicious or not). If we really want it, I would use the *simplest* i.e
use the latest thus one per identity.

Thanks!
David!

> 
> When there’s a conflict, should we order the multiple different commitments in numeric order, rather than time order?
> Time order involves the question of which commitment was received first, which isn’t necessarily consistent between authorities.
> (Does it need to be? If there’s no SR doc, I guess not.)
> 
> Tim (teor)
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)
> 
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)
> 



> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150908/68b61a9a/attachment.sig>