|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com X-Original-To: cryptography@metzdowd.com Date: Wed, 22 Dec 2004 17:24:23 +0000 From: Ben Laurie <ben@algroup.co.uk> To: David Wagner <daw@cs.berkeley.edu> Cc: cryptography@metzdowd.com In-Reply-To: <200412151635.iBFGZeUf008163@taverner.CS.Berkeley.EDU> David Wagner wrote: > Ben Laurie writes: > >>Dan Kaminsky's recent posting seems to have caused some excitement, but >>I really can't see why. In particular, the idea of having two different >>executables with the same checksum has attracted attention. >> >>But the only way I can see to exploit this would be to have code that >>did different things based on the contents of some bitmap. My contention >>is that if the code is open, then it will be obvious that it does >>"something bad" if a bit is tweaked, and so will be suspicious, even if >>the "something bad" is not triggered in the version seen. >> >>So, to exploit this successfully, you need code that cannot or will not >>be inspected. My contention is that any such code is untrusted anyway, >>so being able to change its behaviour on the basis of embedded bitmap >>changes is a parlour trick. You may as well have it ping a website to >>find out whether to misbehave. > > > I guess I disagree. Imagine that the code has some block cipher with > some S-boxes hardcoded into it. The code uses this block cipher to > decrypt an associated ciphertext and outputs (or takes some action based > on) the resulting message. This is an example of code that could be > used to fool a MD5 checksum. Moreover, I don't have a great deal of > confidence that even a careful code inspection would cause the code to > be considered suspicious. Consequently, I don't have great confidence > that such an attack would be detected. Assuming you could find a collision s.t. the resulting decryption looked safe with one version and unsafe with the other (rather than gibberish), which I find an even bigger stretch than the idea that you could find a block that looked safe in one version and unsafe in another, I would have said that the mere fact of using a pointless decryption to control the action of the code would be suspect. > I know it is tempting to think that, look, Wang et al only found a pair > of random-looking messages that collide; they didn't claim to find a pair > of meaningful messages that collide; and maybe we can hope that there is > no way to come up with a pair of meaningful-looking colliding messages. That kind of thinking may tempt you, but it doesn't tempt me. I am not discussing what it might be possible to do, I am discussing what it is possibile to do. > But I think that kind of hope is unfounded, and acting on hope is > asking for trouble. I believe the only safe course now is to assume > that MD5's collision resistance is totally broken. I had assumed that years ago. > If Wang et al can > find meaningless-looking collisions today, it seems all too likely that > someone else may be able to find meaningful-looking collisions tomorrow. > Hoping that the latter will be hard even though the former is known to > be easy seems too optimistic for my tastes. Indeed. Not the point I am making. In a nutshell, yes, it is scary that Wang found collisions. No, it is not _more_ scary that you can use those collisions to fool people who aren't looking anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |