compare_vote_rs() could check more fields for better SHA1 collision resistance
If someone submits descriptors with the same SHA1 hashes, compare_vote_rs() checks a few fields to make sure they are really the same.
We should make sure there is some way of checking all (most?) of the fields. And we should compare new fields when they are added to [vote_]routerstatus_t. But we can't just use a binary comparison, because some of the fields are pointers.
Do we need a new consensus method to add extra tie-breakers?
Here are the fields from vote_routerstatus_t and routerstatus_t, in rough order of size/flexibility/collision-usefulness:
Comparing these is probably necessary, they have 128+ bits of entropy:
- version
- protocols
- exitsummary
- ed25519_id
- ipv6_addr
Comparing these might not be necessary, they only have a few bits:
- ipv6_orport
- measured_bw_kb / bandwidth_kb ?
- guardfraction_percentage
I'm not sure if comparing these is necessary, they probably don't have enough bits to lead to a collision:
- flags / is_x (x is a flag name)
- supports_x (x is a feature name)
- has_guardfraction
- has_measured_bw
- has_ed25519_listing
- has_bandwidth
- has_exitsummary
This is a bug in Tor 0.2.0.3-alpha, which introduced this tie-breaking code. (Or in all the versions since then that added extra fields to [vote_]routerstatus_t, but didn't add them to the tie-breakers.)