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

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Tue, Sep 8, 2015 at 7:10 AM, David Goulet <dgoulet@xxxxxxxxx> wrote:
> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
>>
>> > On 7 Sep 2015, at 23:36, David Goulet <dgoulet@xxxxxxxxx> 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".

It's sufficient to log two conflicting commitments per authority for
the same period in order to prove that a conflict exists.  There's no
reason to keep more.

> 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 say, "Save before publishing, and make sure you don't do two
commitments for one period."  Assuming this kind of accident happens
very rarely, I don't think we need a way to allow it to succeed
anyway.
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev