C. Scott Ananian wrote:
On Wed, 22 Dec 2004, Ben Laurie wrote:
Blimey. Finally. An attack I can actually believe in. Excellent.
Something that is interesting about this issue is that it involves
transitive vulnerability.
If there are only two actors there is no issue. If Alice is the user
and Bob is the software maintainer and Bob is bad, then Alice will be
exploited regardless of the hash function. If Alice is the
This isn't worked out enough to be a proof of concept, but I can imagine
a piece of code that has a comment This can't overflow because value X
computed from the magic bits table will always be between A and B. Get
0.1% speed boost by leaving out range check here but don't change magic
bits.
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
Ben Laurie writes:
Indeed, but what's the point? If you control the binary, just distribute
the malicious version in the first place.
Where this argument breaks down is that someone might have partial
but not total control over the binary. This partial control might
not be enough for them to
On Wed, 15 Dec 2004, Tim Dierks wrote:
Here's an example, although I think it's a stupid one, and agree with
[...]
I send you a binary (say, a library for doing AES encryption) which
you test exhaustively using black-box testing.
The black-box testing would obviously be the mistake. How can you
John Kelsey wrote:
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
Jay Sulzberger wrote:
On Tue, 14 Dec 2004, Ben Laurie wrote:
Ondrej Mikle wrote:
[snipped many assertions without supporting evidence that MD5 cracks
improve attacks]
So, to exploit this successfully, you need code that cannot or will not
be inspected. My contention is that any such code is
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
From: Ben Laurie [EMAIL PROTECTED]
Sent: Dec 22, 2004 12:24 PM
To: David Wagner [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Subject: Re: The Pointlessness of the MD5 attacks
...
Assuming you could find a collision s.t. the resulting decryption looked
safe with one version and unsafe
Well the people doing the checking (a subset of the power users) may
say I checked the source and it has this checksum, and another user
may download that checksum and be subject to MITM and not know it.
Or I could mail you the source and you would check it with checksum
and compare checksum to
Adam Back wrote:
I thought the usual attack posited when one can find a collision on a
source checksum is to make the desired change to source, then tinker
with something less obvious and more malleable like lsbits of a UI
image file until you find your collision on two input source packages.
Bill Frantz wrote:
On 12/14/04, [EMAIL PROTECTED] (Ben Laurie) wrote:
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
Is this the case? Can't we instead start with code C and malicious C'
and try to find a collision on H(C||B) == H(C'||B') after trying 2^64
B values we'll find such a collision by the birthday principle.
Now we can have people review and attest to the correctness of code C,
and then we can MITM
From: Ben Laurie [EMAIL PROTECTED]
Sent: Dec 14, 2004 9:43 AM
To: Cryptography [EMAIL PROTECTED]
Subject: The Pointlessness of the MD5 attacks
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
Adam Back wrote:
Is this the case? Can't we instead start with code C and malicious C'
and try to find a collision on H(C||B) == H(C'||B') after trying 2^64
B values we'll find such a collision by the birthday principle.
Indeed, but that is not the attack suggested.
Now we can have people review
On Tue, 14 Dec 2004 14:43:24 +, Ben Laurie [EMAIL PROTECTED] wrote:
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
Ondrej Mikle wrote:
On Tue, 14 Dec 2004 14:43:24 +, Ben Laurie [EMAIL PROTECTED] wrote:
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
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
I thought the usual attack posited when one can find a collision on a
source checksum is to make the desired change to source, then tinker
with something less obvious and more malleable like lsbits of a UI
image file until you find your collision on two input source packages.
Adam
On Tue, Dec
20 matches
Mail list logo