| |||||||||||||
MD5 collisionsMD5 collisionsPosted Jun 16, 2005 9:54 UTC (Thu) by copsewood (subscriber, #199)Parent article: MD5 collisions
I think the moral of this story is that the person signing something should preferably have a hand in authoring it in a way that will change its hash, e.g. by modifying whitespace in an unpredictable manner, or by adding a few random characters extraneous to the message being signed. Also, given the possibility of document rendering compromise, the least bad signing device is one which is only used for cryptographic applications, is under the physical control of the person signing the document, and can display what is being signed using a simple format prior to signing.
Not that ink on paper signatures are very secure either.
(Log in to post comments)
MD5 collisions Posted Jun 16, 2005 12:32 UTC (Thu) by ekj (guest, #1524) [Link] well-designed digital signature applications (i.e. gpg) already do this.A random (program-selected) number is prepended to the document before hash is computed and signed. So in essence the gpg signature says: "The hash of 35fc1270fb13d260 plus the file is: [so and so]" The published attacks don't work against this. Though offcourse it's possible that other attacks will.
MD5 collisions Posted Jun 16, 2005 12:42 UTC (Thu) by pdc (guest, #1353) [Link] This is one reason why people should be trained to understand the difference between plain text (in the programmer's sense of the word) and more complicated formats like PostScript and Microsoft Word, where a lot of the bytes in the file are invisible in the rendered version. If you look at the PostScript documents used in the paper, the inclusion of invisible binary data is quite obvious; a plain text document would not be vulnerable to this particular attack. Programs for signing documents could be designed to refuse to sign anything except the actual words.
The trick is we want to use signing of binaries to help us avoid trojan-horse device-drivers being put on company's web sites, and in this case, the possibility of adding a binary lump to the executable in order to fiddle the MD5 hash is unavoidable. We could instead insist on drivers being supplied as signed source code to be compiled by the installer (Gentoo style) but in practice source code is a difficult read so it is not likely to be scrutinized in detail by the person who has downloaded it. I can just about imagine a code-signing protocol where a canonical version of the source code is automatically extracted (stripping comments) so that hiding binary junk in the code to fiddle the digest is harder because it has to be compilable.
MD5 collisions Posted Jun 16, 2005 15:55 UTC (Thu) by Ross (subscriber, #4065) [Link] One way to fix this problem is for the signer to add some text to thedocument describing what he or she thinks they are signing.
Another way to minimize the problem is to use different keys for different
|
|||||||||||||