[tor-dev] Update of prop#250: Random Number Generation During Tor Voting
desnacked at riseup.net
Fri Nov 6 13:35:50 UTC 2015
George Kadianakis <desnacked at riseup.net> writes:
> s7r <s7r at sky-ip.org> writes:
>> 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:
Let me know what you think.
More information about the tor-dev