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

[David Goulet]

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:
> 
>      https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250-nosrkeys-v1&id=4a799b3b5b7955a1b3b07475ae341c37b29c1f3b
> 
> 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.

Cheers!
David

> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151106/2b1876d3/attachment-0001.sig>