C. Scott Ananian wrote:
On Wed, 22 Dec 2004, Ben Laurie wrote:
Blimey. Finally. An attack I can actually believe in. Excellent.
D131DD02C5E6EEC4693D9A0698AFF95C2FCAB58712467EAB4004583EB8FB7F8955AD340609F4B30283E488832571415A085125E8F7CDC99FD91DBDF280373C5BD8823E3156348F5BAE6DACD436C919C6DD53E2B487D
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 us
>David Wagner wrote:
>> Ben Laurie writes:
>
>
>> Or, even more contrived, imagine that img1.jpg looks
>> like a completely normal JPG file, but img2.jpg exploits some buffer
>> overrun in the startup screen's JPG decoder to overwrite the program's
>> image with some other malicious code.
>>
>> Su
Ben Laurie wrote:
David Wagner wrote:
To give one contrived example, imagine that the Windows 2010 binary
comes with an image file that is displayed as part of the splash start
screen. Imagine that the graphic designer is allowed to supply that
image, but the graphic designer has no other authoriz
John Kelsey wrote:
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 decryptio
>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 decry
James A. Donald wrote:
--
On 15 Dec 2004 at 8:51, Ben Laurie wrote:
People seem to be having a hard time grasping what I'm trying
to say, so perhaps I should phrase it as a challenge: find me
a scenario where you can use an MD5 collision to mount an
attack in which I could not mount an equally
David Wagner wrote:
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 en
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 t
So, are you sure there can never be a program which allows such an
exploit? I've seen programs that had embedded components (state
machines in particular) which were not easily human-readable, and had
themselves been generated by computer. And even large graphics,
sound, or video sequences ca
On Wed, 15 Dec 2004 10:06:10 -0500 (GMT-05:00), John Kelsey
<[EMAIL PROTECTED]> wrote:
>
> So, are you sure there can never be a program which allows such an exploit?
> I've seen programs that had embedded components (state machines in
> particular) which were not easily human-readable, and had
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 untru
C. Scott Ananian wrote:
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
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
--
On 15 Dec 2004 at 8:51, Ben Laurie wrote:
> People seem to be having a hard time grasping what I'm trying
> to say, so perhaps I should phrase it as a challenge: find me
> a scenario where you can use an MD5 collision to mount an
> attack in which I could not mount an equally effective attac
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 te
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 d
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 tha
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".
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 a
On Wed, 15 Dec 2004 08:51:29 +, Ben Laurie <[EMAIL PROTECTED]> wrote:
> People seem to be having a hard time grasping what I'm trying to say, so
> perhaps I should phrase it as a challenge: find me a scenario where you
> can use an MD5 collision to mount an attack in which I could not mount
> a
On Tue, 14 Dec 2004, Ben Laurie wrote:
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
>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
Adam Back wrote:
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 comp
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 a
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 see to explo
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 s
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.
Quite
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
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 14,
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 d
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
> "somethi
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
33 matches
Mail list logo
