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

[George Kadianakis]

George Kadianakis <desnacked at riseup.net> writes:

> s7r <s7r at sky-ip.org> 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.