[tahoe-dev] SHA-1 broken!

[Perry E. Metzger]

Ray Dillinger <bear at sonic.net> writes:
> I cannot derive a realistic threat model from the very general
> statements in the slides. 

(BTW, you mean threat, not threat *model*, in this instance.)

As just one obvious example of a realistic threat, consider that there
are CAs that will happily sell you certificates that use SHA-1.

Various clever forgery attacks have been used against certs that use
MD5, see:

http://www.win.tue.nl/hashclash/rogue-ca/

Those attacks can now be extended to SHA-1 pretty easily. It might
require a bit of compute infrastructure -- say a lot of FPGAs and a
bunch of cleverness -- to turn out certs quickly, but it can be
done. Given that there are lots of high value certs out there of this
form, this is rather dangerous.

For example, Verisign has lots of cert infrastructure right now that
uses SHA-1. Imagine if I now use the above described attack and start
forging certs that look to all the world like they're from Verisign and
claim that I'm a major bank, or to forge a CA that then forges certs
that claim I'm a major bank. "Ooops!"

> In the case of, for example, the Debian organization, which uses SHA-1 
> keys to check in code so that it's always clear with a distributed 
> network of developers who made what changes, What threats must they 
> now guard against and what corrective measures ought they take?

One can easily imagine a forgery attack right now where someone
presented you with one piece of code which you sign and then made use of
a different piece of code with the exact same SHA-1 which you didn't
intend to sign. I don't know if Debian's specific processes are
vulnerable or not to various clever attacks -- it would require a lot of
thinking even if I was familiar enough with them, and I'm not.

So, use something other than SHA-1 -- SHA-256 at least. Don't panic,
don't flail around like a headless chicken, but do move away with all
deliberate speed.

> Can a third-party attacker now forge someone's signature and check in 
> code containing a backdoor under someone else's key?

Perhaps, if they're clever enough. The most obvious attacks require
preimage weaknesses, and those aren't known yet. However clever people
can find ways to get around this -- see the "Rogue CA" attack -- and
cause havoc.

> Is it the case that a constructed hash collision between A and B 
> can be done by a third party but would be highly unlikely to contain 
> any executable or sensible code at all?

See the "Rogue CA attack" -- by being clever enough, one can almost
certainly produce two executables with the same SHA-1 hash. They would
need some sort of area that varied, but that's not too hard -- ELF note
sections, data segments regions that contain some blob of data you don't
care about, etc., are all fine possibilities.

So, don't use SHA-1 if you can help it. This is not to say that all uses
are unsafe. There is also no need to panic. However, it is clearly not a
good idea to continue using it.

Perry
-- 
Perry E. Metzger		perry at piermont.com

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