[p2p-hackers] SHA1 broken?

[Jacob Langseth]

> --- begin forwarded text
> 
> 
> To: p2p-hackers at zgp.org
> Subject: Re: [p2p-hackers] SHA1 broken?
> Date: Thu, 17 Feb 2005 14:25:36 -0800 (PST)
> From: hal at finney.org ("Hal Finney")

[...]

> Now, it would be a big leap from this to being able to take two arbitrary
> different initial values and bring them together to a common output.
> That is what would be necessary to mount the code fraud attack.  But as
> we can see by inspection of the collisions produced by the researchers
> (who are keeping their methodology secret for now), they don't seem to
> have that power.  Instead, they are able to introduce a very carefully
> controlled difference between the two blocks, and then cancel it.
> Being able to cancel a huge difference between blocks would be a problem
> of an entirely different magnitude.
> 
> Now, there is this other idea which Zooko alludes to, from Dan Kaminsky,
> www.doxpara.com, which could exploit the power of the new attacks to
> do something malicious.  Let us grant that the only ability we have is
> that we can create slightly different pairs of blocks that collide.
> We can't meaningfully control the contents of these blocks, and they
> will differ in only a few bits.  And these blocks have to be inserted
> into a program being distributed, which will have two versions that
> are *exactly the same* except for the few bits of difference between
> the blocks.  This way the two versions will have the same hash, and
> this is the power which the current attacks seem to have.
>
> Kaminsky shows that you could still have "good" and "bad" versions of
> such a program.  You'd have to write a program which tested a bit in
> the colliding blocks, and behaved "good" if the bit was set, and "bad"
> if the bit was clear.  When someone reviewed this program, they'd see
> the potential bad behavior, but they'd also see that the behavior was
> not enabled because the bit that enabled it was not set.  Maybe the



I would have to argue that a single bit could indeed constitute
enough of a difference to represent a security vulnerability.

There have been a number of security issues that have occured due
to an underlying integer wrap vulnerability; what if the single bit
that was changed was the MSB of a length field in an often unused
code path, that when properly manipulated, resulted in a controllable
heap ovewrite?

The difference would be subtle, only a single bit, which fits
with the attack.  Exploitable examples, where by flipping the
MSB is enough to allow an attack, are known in the computer
security field.  One doesn't need to include the entire back
door to cause a problem.

 Jacob

-- 
Jacob Langseth <jwl at pobox.com>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com