
Ever Better Cryptanalytic Results Against SHA-1 - soundsop
http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html
======
smanek
Just to clarify, this makes a collision attack feasible, not a preimage
attack.

That means (iirc) someone can create two messages that have the same hash -
but not create a message that has a particular hash.

Still not ideal - but not terrible. It still wouldn't be feasible, for
example, to bruteforce a password from its hash.

~~~
tc
You can still inflict a lot of damage if you can create collisions. Producing
a rogue CA is just one possibility.

<http://www.phreedom.org/research/rogue-ca/>

The potential for intentional collisions makes it critical that an attacker
cannot control or predict all of the inputs to your signing operation.

------
liuliu
<http://news.ycombinator.com/item?id=606026>

collision attack is enough to break git.

~~~
biohacker42
Any git developers here? How much work would it be to swap SHA1 with something
stronger?

~~~
reconbot
I'm not a git developer, but I remember from linus's google tech talk that it
would be pretty trivial, and you can already use your favorite hashes. I don't
know anything about repo compatibility. But this wont break git, your source
files will still have the same likely hood of producing a collision as they
always have, nil. This just means that git could possibly be subject to
attack, and that gpg signing sha1 hashes may not be 100% the best method of
saying the following code is trusted. But I seriously doubt any sort of
injection would compile.

 _EDIT:_ Thinking about it, you could have a commented area somewhere where
you put in garbage characters to try to generate a collision, not unlike
producing two word documents that read slightly different (different clauses
in a contract for example) but have a ton of random metadata that causes the
collision. But this isn't an attack on SHA1 just on hashes in general.

------
billpg
An attack would be if I build a two documents with the same hash and get
someone to sign one of them.

Why would anyone do that? Perhaps they open the document and see its all good
stuff, but don't spot all the hidden comments (like HTML's <!--) which are
there to make the collision work.

It would be a good practise anyway, that if you routinely sign files other
people produce, to add your own blob of randomness as an extra hidden comment
to the document you sign.

~~~
niyazpk
_An attack would be if I build a two documents with the same hash and get
someone to sign one of them._

That is not possible using this attack. This is just a collision atttack, not
a preimage attack.

 _It would be a good practise anyway, that if you routinely sign files other
people produce, to add your own blob of randomness as an extra hidden comment
to the document you sign._

I don't think people will trust you anymore if you start adding your own data
to the documents you sign.

~~~
cstejerean
I'm confused, doesn't "collision attack" mean being able to create two (or
more) documents with an identical hash? (As opposed to preimage attacks which
involve creating documents that have a given hash).

So why would that prevent the attack billpg described?

~~~
niyazpk
You are correct. That is exactly why this attack cannot be used to forge
documents (at least in a direct way)!

To forge a document, you need to find another document having the same hash.
So it is a preimage attack.

Using a collision attack you can find collisions in the hash space, but that
is not useful directly.

