Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

[s7r <s7r@xxxxxxxxxx>]

-----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:
> 
> 1) 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.
> 
> 2) 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!
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWOsThAAoJEIN/pSyBJlsRHA4H/1yRGAW38Qnbr3Z1mHg/XM0L
U3ALLZjrDU320ApGS1c7zZ0nd1Y3kl3/mZla23bpcMs86RRsiY21HSTEcqYKZ/aO
MVCxxQvaHtcgz4urILi5FeZiSWyFfjW2xlC0iSS4h7JJlILKP+9UX6n0CrDwE7Te
kLnOhFGaS1f8CYICQef4T3M1ZPQ5sTT95Sl8UAPZTsx0CWbm02dSDCZzEF1H1RFR
QvgVD+XNsdSbAik7dGw5VQ3In/KcL/dl1gUPKhzDFyey6ZZ80gCViLOBgR5BthgS
b392gm/xJY2jOn5fIH5ekjwrpKSHAkBNrTNLZiQFr+Trk3kOHngZszcPGY7qEy8=
=vRde
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev