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

[s7r <s7r@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I am fine with that.There is no sense going only half way here. So,
without the conflict code, there is no sense keeping a SR key. The
only source of authentication will be the normal signature of the vote.

We should keep the older version of the proposal (with conflict  code
and SR key) and the code in a branch somewhere, and the design in our
heads, so we can get back to it in the future if we need to do so.

For the old version of the proposal (with conflict code) I think we
should add/change:

- - It is mandatory to sign with the SR key REVEAL in a separate
REVEAL_BROADCAST saved to persistent. Only the signed REVEAL will be
broadcasted in the reveal phase, so authorities can participate only
in this phase of the protocol.

- - SR key should have the same lifetime as SigningKeyLifetime and use
the need_new_signing_key and want_new_signing_key as per the logic
described in my previous email on trac.

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 randomness calculation for the day.

This does not have a significant effect over the partitioning attack
(which we agreed there's no sense addressing) but it may prevent
consensus conflicts that could lead to SRDISASTER or accidental
partitioning, in case an authority simply joins too late and for a
reason or other doesn't catch up with the rest of the votes from other
authorities. Plus, I don't see a reason for why we shouldn't require
this - the probability for an authority to be genuinely available
_only_ for the last reveal round is reasonably low. Also, if an
authority was absent for > 23 hours in a day, not allowing it to
participate in the shared randomness calculation for that day only is
not an unusual or abusive punishment.

If an authority was present and voted in that protocol run before hour
- -3, but missed hour -3, it should be allowed to participate. Basically
require to have at least 3 reveal votes in the reveal phase of a
single day to make sure it has quite low chances not to be in sync. Or
we could only require the last 3 reveal rounds from 21:00 UTC or hour
- -3 to hour 0.

This will be decided just by looking from code simplicity point of
view, as in terms of security and followed goal both provide the same
effect. I am equally fine with both approaches (but it's very much
more unlikely to miss 3 rounds (votes) during ALL the reveal phase as
opposite to missing the last 3 consecutive ones).

What do you think?



On 11/6/2015 3:35 PM, George Kadianakis wrote:
> George Kadianakis <desnacked@xxxxxxxxxx> writes:
> 
>> s7r <s7r@xxxxxxxxxx> writes:
>> 
>>> Hello,
>>> 
>>> <snip>
>>> 
>>> 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 sign the REVEAL value with the SR
>>> key for broadcasting, besides keeping the unsigned one for
>>> computing COMMIT which obviously needs a separate signature. It
>>> provides some security against little effort. Useful for
>>> directory authorities who miss the commitment phase and only
>>> participate in the reveal phase. Something like this (switched
>>> TIMESTAMP's place at the end):
>>> 
>>> REVEAL = base64-encode( RN || TIMESTAMP ) SIGNATURE =
>>> ed25519-sign( privkey=PRIVKEY, msg=RN || TIMESTAMP ) 
>>> REVEAL_BROADCAST = base64-encode( RN || TIMESTAMP || SIGNATURE
>>> )
>>> 
>>> where the signature is performed using a special shared
>>> randomness ed25519 key [SRKEY].
>>> 
>> 
>> To be honest now that we removed the conflict detection code, the
>> SR keys are almost useless, since there is already origin proof
>> for authoritative commits/reveals by listing them on the signed
>> vote.
>> 
>> I'm kinda contemplating removing the SR keys altogether, since
>> that would remove another good 500+ lines of code. It would also
>> simplify considerably our commit/reveal generation and
>> verification procedures. It would also speed up the code review
>> procedure.
>> 
>> I'm kind of sad for us killing all that nice code, but hey we can
>> keep it in a branch and use it when we actually need to.
>> 
>> Let me know what you think here. Maybe i'm crazy.
> 
> and here is a spec change for this suggestion:
> 
> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250-nosrkeys-v1&id=4a799b3b5b7955a1b3b07475ae341c37b29c1f3b
>
>  Let me know what you think.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWPkVGAAoJEIN/pSyBJlsRLv8H/RXCZJWJWFk75T9yyWq6au49
gZ5IKclJhX/3D+RXR+SWUXbUvDyZvuIg4dX+Pssrn1tu6mSI2smGYvpFf13EcKKr
QxN714TkYqvGuLLgKpJAsAHK90d6IBXqRxDxUJePY6ScyB9KjnD9DWW/QzKrHPDR
qfqUIiCZ810GPOqf2+J8iqVW/To5TC/6W5cyIhwN0MPzs9pB/AWXiEcJ/fcJnzqb
/ZRJYx1PmK1j5ENZPJjBMdAh6S7UsYaGPWsEMHivVexr32KXffVObdtFfgoqzTBx
SJd1SHpfvI2rJZzl9WEtoKDOXBo82Lgsg3+GNpx45PvEcrTkaxsS/tZhV+f81z4=
=K//a
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev