[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

use of md5sum for tally sheet

I'm not a cryptographer so I could be way off here. Could there be a
problem with using the MD5 hash in the tally sheet? My concern is purely
theoretic and I have absolutely no reason to doubt the secretary!

When I submit my vote (for DPL elections) I receive a confirmation email
with a moniker of FOO (as far as I can determine I don't have any
influence of the chosen moniker). After the vote I check that the hash:
  echo "adejong FOO" | md5sum
is in the tally sheet and has the correct vote (everybody does this
right?). So far so good.

The problem arises with the recent discoveries in hash-collisions for
MD5. Is it possible to construct a moniker BAR that for another
developer would result in the same MD5 hash as mine? If so, this could
be exploited so that two developers look at the same row in the tally
sheet and see their vote there (provided they voted the same). This
would leave a row in the tally sheet that could be stuffed with a random
MD5 hash and a vote of the secretary's choosing.

This problem would of course be detected in a recount of the votes
(signed emails) but it will not be detected from checking the tally
sheet. Also, this problem obviously applies only to DPL elections as
other votes are not anonymous.

Again, I'm not doubting the integrity of the secretary and the ongoing
vote. I'm just asking if this is purely theoretical or becoming

This issue was raised before:
and dismissed as impractical. A method for constructing MD5 collisions
has been developed since then and I think the hashing landscape has
changed somewhat so I think the question should be asked again.

Some references on the MD5 collisions:
These mainly describe inserting binary data in messages of around 1K.
The data we're hashing is all ASCII and much shorter. Also it seems that
most attacks insert a magic prefix rather than a suffix (and our moniker
is at the back). This would suggest that there is not yet a ready-made
attack available that would work in our case.

A quick fix for this problem would be to also use a SHA1 (or other) hash
with the SAME moniker (assuming finding a moniker that would result in a
MD5 and SHA1 collision is still impractical). Another solution would be
to let the voter choose the moniker. This could however have an
influence on the anonymity of the vote. Better solutions can probably be
found though.

On a slightly (but not really) related note, would it be possible to get
the tally sheet signed and sent to debian-vote after the vote? This
would make tampering with the tally sheet after the vote harder.

-- arthur - adejong@debian.org - http://people.debian.org/~adejong --

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: