-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
I am fine with that.There is no sense going only half way here. So, without the conflict code, there is no sense keeping a SR key. The only source of authentication will be the normal signature of the vote.
We should keep the older version of the proposal (with conflict code and SR key) and the code in a branch somewhere, and the design in our heads, so we can get back to it in the future if we need to do so.
For the old version of the proposal (with conflict code) I think we should add/change:
- - It is mandatory to sign with the SR key REVEAL in a separate REVEAL_BROADCAST saved to persistent. Only the signed REVEAL will be broadcasted in the reveal phase, so authorities can participate only in this phase of the protocol.
- - SR key should have the same lifetime as SigningKeyLifetime and use the need_new_signing_key and want_new_signing_key as per the logic described in my previous email on trac.
For all versions of the proposal, regardless if we use the conflict code or not, I think we should require authorities to participate for at least for 3 rounds of the reveal phase, otherwise not participate in the shared randomness calculation for the day.
This does not have a significant effect over the partitioning attack (which we agreed there's no sense addressing) but it may prevent consensus conflicts that could lead to SRDISASTER or accidental partitioning, in case an authority simply joins too late and for a reason or other doesn't catch up with the rest of the votes from other authorities. Plus, I don't see a reason for why we shouldn't require this - the probability for an authority to be genuinely available _only_ for the last reveal round is reasonably low. Also, if an authority was absent for > 23 hours in a day, not allowing it to participate in the shared randomness calculation for that day only is not an unusual or abusive punishment.
If an authority was present and voted in that protocol run before hour - -3, but missed hour -3, it should be allowed to participate. Basically require to have at least 3 reveal votes in the reveal phase of a single day to make sure it has quite low chances not to be in sync. Or we could only require the last 3 reveal rounds from 21:00 UTC or hour - -3 to hour 0.
This will be decided just by looking from code simplicity point of view, as in terms of security and followed goal both provide the same effect. I am equally fine with both approaches (but it's very much more unlikely to miss 3 rounds (votes) during ALL the reveal phase as opposite to missing the last 3 consecutive ones).
What do you think?
On 11/6/2015 3:35 PM, 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-nosrkey...
Let me know what you think.