On 06 Nov (15:35:50), George Kadianakis wrote:
George Kadianakis desnacked@riseup.net writes:
s7r s7r@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=4a799b3b5b7955a1b3b07475ae341c37b29c1f3bLet 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev