Ever Better Cryptanalytic Results Against SHA-1 | Hacker News Reader

Ever Better Cryptanalytic Results Against SHA-1

schneier.com

33 pointssoundsop10 comments

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.

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.

http://news.ycombinator.com/item?id=606026

collision attack is enough to break git.

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

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.

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.

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.

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?

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.

Wrong sort of attack. My bad.

Reply on news.ycombinator.com