Re: Collisions for hash functions: how to exlain them to your boss
From: Eric Rescorla [EMAIL PROTECTED] Sent: Jun 14, 2005 9:36 AM Subject: Re: Collisions for hash functions: how to exlain them to your boss [Discussing the MD5 attacks and their practicality, especially the recent postscript demonstration.] ... But everything you've just said applies equally to my JavaScript example. It's not a security vulnerability in the browser or the data format that it displays differently depending on the context. It's an intentional feature! I think our disagreement here has to do with what we're seeing from the attack. You're seeing a specific attack vector--use conditional execution/display + the ability to find specific collisions of a particular form to yield these nice attacks where we have two messages that amount to X ||M0||M1 X*||M0||M1 where when the first part of the message is X, some kind of conditional execution displays M0, while X* leads to the display of M1. And I think you're right to say that in many cases, once you're viewing the result of blindly executing programs that I send you, you're vulnerable to other attacks that are about as damaging. Now, it's certainly possible imagine cases where this kind of conditional execution wouldn't be allowed to access anything outside the file, but once you've decided to put in a full featured scripting language, it's not that much of a stretch to think you'll let me read the system time. I'm seeing a more general pattern of attacks, in which X and X* amount to context for the display of whatever follows them. That seems to me to encompass a lot more than macros and script files with conditional execution. And even when I don't have a specific attack in mind, it worries me that if I'm trying to help someone safely use MD5, I've got to think through whether there is any way at all to make this kind of attack pattern work. It's a heck of a lot easier to say don't use MD5. ... -Ekr --John Kelsey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Collisions for hash functions: how to exlain them to your boss
Stefan Lucks [EMAIL PROTECTED] writes: Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... While this is a clever idea, I'm not sure that it means what you imply it means. The primary thing that makes your attack work is that the victim is signing a program which he is only able to observe mediated through his viewer. But once you're willing to do that, you've got a problem even in the absence of collisions, because it's easy to write a program which shows different users different content even if you without hash collisions. You just need to be able to write conditionals. For more, including an example, see: http://www.educatedguesswork.org/movabletype/archives/2005/06/md5_collisions.html -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Collisions for hash functions: how to exlain them to your boss
Hi Eric, Technically speaking you're correct, they're signing a program. But most people, certainly non-techies like Alice's boss, view postscript (or MS Word, or name your favourite document format that allows macros) files not as programs but as static data. In being targeted at non-techies I find this attack more convincing than those of Mikle and Kaminsky, though essentially it's a very similar idea. Note that opening the postscript files in an ASCII-editor (or HEX-editor) immediately reveals the attack. Stefan Lucks told me they might be able to obfuscate the postscript code, but again this will only fool the superficial auditor. Grtz, Benne = Technische Universiteit Eindhoven Coding Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 tel. (040) 247 2704, bgg 5141 e-mail: [EMAIL PROTECTED] www: http://www.win.tue.nl/~bdeweger = -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla Sent: maandag 13 juni 2005 17:05 To: Stefan Lucks Cc: cryptography@metzdowd.com Subject: Re: Collisions for hash functions: how to exlain them to your boss Stefan Lucks [EMAIL PROTECTED] writes: Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... While this is a clever idea, I'm not sure that it means what you imply it means. The primary thing that makes your attack work is that the victim is signing a program which he is only able to observe mediated through his viewer. But once you're willing to do that, you've got a problem even in the absence of collisions, because it's easy to write a program which shows different users different content even if you without hash collisions. You just need to be able to write conditionals. For more, including an example, see: http://www.educatedguesswork.org/movabletype/archives/2005/06/ md5_collisions.html -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Collisions for hash functions: how to exlain them to your boss
Weger, B.M.M. de [EMAIL PROTECTED] writes: Technically speaking you're correct, they're signing a program. But most people, certainly non-techies like Alice's boss, view postscript (or MS Word, or name your favourite document format that allows macros) files not as programs but as static data. In being targeted at non-techies I find this attack more convincing than those of Mikle and Kaminsky, though essentially it's a very similar idea. Note that opening the postscript files in an ASCII-editor (or HEX-editor) immediately reveals the attack. Stefan Lucks told me they might be able to obfuscate the postscript code, but again this will only fool the superficial auditor. Yes, this is all true, but it's kind of orthogonal to my point, which is that if you're willing to execute a program, this attack can be mounted *without* the ability to produce hash collisions. The fact that so few people regard PS, HTML, Word, etc. as software just makes this point that much sharper. As far as I can tell, the ability fo produce hash collisions just makes the attack marginally worse. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Collisions for hash functions: how to exlain them to your boss
Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... Have fun Stefan -- Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany e-mail: [EMAIL PROTECTED] home: http://th.informatik.uni-mannheim.de/people/lucks/ -- I love the taste of Cryptanalysis in the morning! -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
