-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
asn,
Is it possible to add a field called 'NOTARY' in the COMMIT and REVEAL values where we include the SR pubkey + certificates and everything we need so that we can validate each COMMIT / REVEAL value and tie it to the identity of a directory authority any time?
Directory authorities will save to disk each COMMIT and REVEAL including the data required for signature validation (NOTARY field). Each authorities will include it in their votes also, and so on.
This way an authority can even use a different SR key for each COMMIT value broadcasted in a single day, if it's properly chained to the identity of that authority at the timestamp of the usage which is also recorded and individually verified.
This is what I was trying to suggest in the last part of my comment on #17349 but written it kind of pour there - I was confused about your 'other authorities save the SR key to disk statement' initially but it made total sense after reading the final complete proposal.
What if an authority changes shared random signing keys partway through a round?
Good question! Fortunately, I think we can handle this.
First, we include the shared randomness key in the votes of each dirauth, then we also mandate that the authoritative commitments in each vote are signed by the current shared randomness key. This means that other dirauths should always be able to verify the signatures of the commitments in a vote.
Here is a proposed procedure to handle key rotation:
- When Alice receives a valid commitment from dirauth Bob, it
saves the commitment values (timestamp, H(REVEAL), etc.) and the shared randomness public key in its state.
- When Alice, later in the protocol run, receives another valid
commitment from dirauth Bob, it needs to verify the new signature and check that the commitment values *did not change*.
If the signature is valid and the commitment values are the same, then we consider the commitment and authority trusted. How does that sound to you?
We should probably write this procedure down in the spec, maybe.
And we should also have tests to ensure that this works smoothly, because as you said it definitely happen eventually.
However, key rotation *does* make the commit conflict mechanism more complicated.
The reason is that when Alice receives a conflict line from dirauth Bob:
"shared-rand-conflict" SP identity SP commit1 SP commit2 NL
she doesn't know which shared randomness key to use for which commit.
If she already knows a shared randomness key for 'identity', then she can try to use that to verify both signatures. However, the conflicting attacker could have rotated shared randomness keys and could have signed 'commit2' using a different SR key than 'commit1'. In this case, if Alice does not know both SR keys, she is unable to verify the validity of the conflict line. In that case, should she trust the conflict line or not?
I guess not, otherwise Bob could just craft fake conflict lines and feed them to other auths. However, if we don't trust the conflict line, then the attacker can again partition the authorities by causing everyone to ignore Bob's conflict line, whereas Bob will of course trust his own judgement.
A way to work around that problem would be if instead of 'identity', we include both cert chains in the "shared-rand-conflict" line so that the shared randomness keys are always available for verification.
But this adds extra complexity and logic to the conflict mechanism which is kind of useless anyway, since it only defends against dumb attacks.
Does anyone have another procedure for validating shared-rand-conflict lines that makes more sense?
Thanks!