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 practical? This issue was raised before: http://lists.debian.org/debian-vote/2003/03/msg00114.html 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: http://www.cryptography.com/cnews/hash.html http://www.cits.rub.de/MD5Collisions/ http://en.wikipedia.org/wiki/Md5 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