Ray Dillinger <b...@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 pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com