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-nosrkey...
Let me know what you think.