[tor-dev] Update of prop#250: Random Number Generation During Tor Voting
dgoulet at ev0ke.net
Fri Nov 6 18:06:43 UTC 2015
On 06 Nov (15:35:50), George Kadianakis wrote:
> 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:
> Let me know what you think.
It's indeed weird to keep lots of code and a section in the proposal
that actually is useless. The only argument I can see to keep it is for
"future use" if we want to start addressing partition attack directly in
the code for instance or other _unknown_ design flaw.
That being said, I think we can knife it. The code will still exists in
a branch somewhere and we are starting to get quite a good understanding
of the problem space here ;).
Now question about the commit above ^:
+ where the ID_a value is the identity key fingerprint of authority 'a' and R_a
+ is the corresponding reveal value of that authority for the current period.
We had this discussion before and also asked Nick about this. We should
_NOT_ use the RSA key here of the authority and as far as I know we
don't have the ed25519 key of an authority accessible in the vote?
Also, the TIMESTAMP was removed. Can you explain why? I like it even
though it doesn't have a direct practical use in the protocol. With it
we can know when the authority generated its commit and it's an extra
nice check to match commit/reveal value (you know avoiding unknown crazy
replay attack :P). I see it useful for debugging potential issues in the
long run since in the vote (and sr-state) we'll have a data point on
when the authority did generate that commitment.
Apart from that, I vote go on the removal of SR keys.
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: Digital signature
More information about the tor-dev