By adding 6 lines to the code of GPGMail, I’ve allowed it to send messages with some (perhaps) less compromised hashing algorithms. Generally an algorithm called SHA-1 is used to generate a condensed representation or “hash” of the text PGP/GPG messages for signing purposes. The SHA-1 algorithm is subject to an attack described by Chinese researchers that allows another text that generates the same hash (called a “collision”) to be found in 269 steps rather than the 280 steps that the original design specified. This attack makes finding a collision several orders of magnitude faster.
Collisions are hazardous in that a powerful adversary (usually named Mallory) could take a note you signed that said “I like cashews” and generate a new note with some variation of “I agree to sell my home to Mallory for $15.–” With plaintext messages this is a lot harder because generally one must add random garbage to the end of the message, but with files that do (or could) have a lot of unused junk data in them such as Microsoft Word this is a lot easier. Many prominent figures in the cryptographic community have weighed in on the need to move away from SHA-1.
GPGMail.mailbundle right now only allows SHA-1, MD5 (subject to its own collision attacks), and RIPEMD-160. Adding a few lines of code allows users like me to send messages also with SHA-256, SHA-384, and SHA-512. A zip of this updated mailbundle is attached for existing GPGMail users. It depends on all the same sorts of things that the usual GPGMail depends on, check the GPGMail web page for details. You also have to make a configuration change and generate an RSA signing key in order to use the newer algorithms:
- Add the line
digest-algo sha512to .gnupg/gpg.conf (or
sha384if you prefer)
- Generate an RSA signing subkey by running
gpg --edit-key firstname.lastname@example.org
- Enter your password at the prompt
- Pick the number for
RSA (sign only)and finish the configuration of your key
It’s not time to panic and run away from SHA-1, but now is the time to migrate away from it if possible. People who are picky about standards will note that using these new algorithms is not strictly allowed by the OpenPGP RFC. There are revisions floating within the IETF to fix this, but standards processes move a lot like glaciers.