On 06 Nov (15:35:50), George Kadianakis wrote: > George Kadianakis <desnacked@xxxxxxxxxx> writes: > > > s7r <s7r@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev