Preparing To Migrate Off of SHA-1 In OpenPGP
jamie found a note on debian-administration.org, the first in a promised series on migrating off of SHA-1 in OpenPGP. "Last week at eurocrypt, a small group of researchers announced a fairly serious attack against the SHA-1 digest algorithm, which is used in many cryptosystems, including OpenPGP. The general consensus is that we should be 'moving in an orderly fashion toward the theater exits,' deprecating SHA-1 where possible with an eye toward abandoning it soon (one point of reference: US govt. federal agencies have been directed to cease all reliance on SHA-1 by the end of 2010, and this directive was issued before the latest results). ... So what can you do to help facilitate the move away from SHA-1? I'll outline three steps that current gpg users can do today, and then I'll walk through how to do each one..."
'moving in an orderly fashion toward the theater exits'
An elderly application was trampled to death today as everyone struggled to exit the Sha One theater after someone screamed that an unknown assailant had a knife. After the panic, there was no evidence of injuries from the alleged attack and police are still investigating the presence of an actual weapon.
My work here is dung.
Perfect security is not feasible. "Secure enough" changes over time.
From TFA, so others don't have to read it, GPG will stay with SHA 224, SHA 256, SHA 384 and SHA 512.
Rethinking email
Is there any hash function that actually is secure?
There are some for which no known attacks exist. SHA-256 and SHA-512, Whirlpool and Tiger are all pretty thoroughly-reviewed with no weaknesses uncovered. The NIST hash function competition is causing a great deal of new hash function research and we'll almost certainly get a bunch of great new hash functions out of it -- many of them not only secure, but significantly faster than SHA-1.
If you're thinking that "no known attacks" isn't good enough, keep in mind that's as good as it every gets in cryptography, with the sole exception of the One Time Pad
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I guess I'll just go back to good old MD5.
That is not what secure means with regard to hash functions. Secure means that it is not feasible to construct a document which has the same hash value as a given document (pre-image attack) or to construct two documents which have the same hash value (collision attack). The complexity of these attacks is ideally such that simply enumerating documents is the fastest way (brute force). Reducing the number of documents which you have to try to find a match makes a successful attack more likely. The complexity which is deemed as breaking the hash function depends on the adversaries and time frames relevant to a particular application.
SHA-1 doesn't encrypt things. It makes a hash of them, to verify they haven't been modified.
There are no secrets encrypted with SHA-1 because SHA-1 doesn't encrypt things.
Guess the Aussies overpaid, since their $560k "unbreakable" cryptosystem relies on SHA-1. Shock of shocks, I know...
Oh god, that woman is John Romero!
One specific thing that would really help would be if debian would make it a priority to do a complete job of packaging the relevant hash functions, along with bindings for popular languages. For instance, I have an open-source perl app that uses digital watermarks. The user can choose between SHA1 and Whirlpool. However, I want to keep my app simple for users to install, and the perl binding for Whirlpool hasn't been packaged for debian yet, so I've made SHA1 the default. A debian user who wants to use Whirlpool with my app has to jump through hoops, e.g., installing the perl module via CPAN. That's actually a real pain for a debian or ubuntu user, because CPAN and apt don't play nicely; you can get in all kinds of screwed-up states if you try to install half your perl modules using apt and half using CPAN.
TFA is talking about gpg. Well, realistically, the choice of hash function is not the bottleneck in terms of security when it comes to sending encrypted or signed email. The bottleneck is mainly just that it's too hard to use (isn't built in to most GUI email clients), and in the case of encryption it also suffers from negative network effects -- there's no big benefit to me from using gpg encryption in my email unless the people I'm communicating also use the technology. The world's best crypto doesn't do you any good if you don't use it because it's too much of a pain. I think gpg is clearly a case where the perfect has been the enemy of the good. They've been so hung up on protecting the user against obscure vulnerabilities that they've ended up making the darn thing too hard for the vast majority of users. The docs, last time I checked, were basically written in Martian. I have a bachelor's degree in math, I program computers as a hobby, and I've read Schneier's Applied Cryptography. I'm not claiming that makes me a big expert on crypto, but it does put me out in front of the vast majority of the population. Well, I simply cannot figure out all the ins and outs of gpg. Okay, I could, but it would take more time than I'm willing to invest.
Find free books.
If you're thinking that "no known attacks" isn't good enough, keep in mind that's as good as it every gets in cryptography
I think my math teacher would call that a "necessary but not sufficient" condition, I mean anything can be without known attacks by virtue of never having been reviewed. Minimums should include:
1. Published algorithm, no "secret sauce" security by obscurity
2. Solid peer reviews by other cryptographers, definately not just the vendor or their hirelings
3. Strong links to well-researched hard mathematical problems
Of course, nothing can guarantee that the NSA hasn't found some super-secret math thingie that'll cut through it like a knife through hot butter. But cryptography is also about eating your own dog food, if you don't use it for anything valuable who'd trust it? You can't really keep that a secret because you have to tell lots of people that this isn't really secure or they'd use it as if it were. And if you do use it for your valuables, would you really leave that kind of backdoor for someone else to find? Again it doesn't prove anything, but I think most modern crypto algorithms have no weaknesses known to anybody, and if one showed up it'd be just as big a OMG for those who made/approved it as everyone else.
Live today, because you never know what tomorrow brings
I'm not so sure he's talking about applying one hash to the other's output, as much as performing both hashes on the same material and storing both results, also checking both results. Then you'd have to create a collision for both hashes in order to beat the system.
http://lkml.org/lkml/2005/8/20/95
This has nothing to do with multiple hash algorithms. What you're referring to is that finding an n-way collision from a 2-way collision is polynomial time. That is, a 2-way collision is two documents with the same hash, and an n-way collision is n documents with the same hash.
Finding a pair of documents that have the same SHA1 hash doesn't help you find a pair of documents with the same MD5 hash. Indeed, none of the efficient-collision algorithms allow you to find collisions in both SHA1 and MD5 simultaneously. (Note that, as far as I know, there aren't even any efficient preimage attacks on MD5 or SHA1, only collision attacks.)
Using multiple hash algorithms is helpful, yes.
According to x509(1) and ca(1), OpenSSL supports md2, md5, sha1, and mdc2 as options for message digests for certificates. Since MD2 and MD5 are already broken, and SHA1 is now suspect, that leaves just the relatively obscure MDC-2.
Did no one really reply to this?
PGP is the original. Phil Zimmerman, export control, all the history.
OpenPGP is a specification for all input and output of a PGP system. RFC 4880. Diverges from PGP5.
GPG == GNUPG. A Free Software implementation of OpenPGP. Has now become the most commonly used OpenPGP implementation. Werner Koch is the project lead.
-molo
Using your sig line to advertise for friends is lame.