GnuPG 2.1.0 "modern" released [LWN.net]

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:26 UTC (Thu) by dkg (subscriber, #55359)
In reply to: GnuPG 2.1.0 "modern" released by epa
Parent article: GnuPG 2.1.0 "modern" released

I'm sorry, but "at some future date" hasn't been true for MD5 for years. MD5-based signatures were forged back in 2008.

epa wrote:

I invite you to take a message signed with an older key and produce a forgery with the same signature.

First: the issue isn't whether some arbitrary LWN commenter has the time, resources, and skills to mount such an attack (though i agree if they can, that's really bad for the digest). The problem is whether a dedicated adversary has the time, resources, and skills.

Secondly: i acknowledge that the sort of attacks mounted by the rogue CA project referenced above were attacks against MD5's collision-resistance, which shouldn't be possible to mount against an existing signature, because this form of attack needs the victim to continue making signatures in the present, against data that is under the attacker's control at some level. But the tool that verifies such a signature (GnuPG) has no way of knowing whether such a thing is happening. The only thing the tools sees is the signed data and the signature itself.

So if the tool is going to make any conclusive statement (like "this signature is valid and was made by the key in question over the data you see here"), it can't be sure. Cryptographic tools need to provide strong assurances, and GnuPG (or anything else at this point) simply can't provide those assurances over data that is signed with an MD5 digest any more, because the digest is not cryptographically reliable.

GnuPG has done the right thing by dropping this support.

to post comments

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 18:28 UTC (Thu) by epa (subscriber, #39769) [Link] (19 responses)

First: the issue isn't whether some arbitrary LWN commenter has the time, resources, and skills to mount such an attack (though i agree if they can, that's really bad for the digest). The problem is whether a dedicated adversary has the time, resources, and skills.

It really depends on your application. A dedicated adversary has the ability to tap my phone line, but that does not stop me personally from using telephone banking. Others will have more stringent requirements. There certainly is value in cryptography which is strong enough to stop any adversary short of a dedicated supercomputer-backed attack by Mossad or whatever your preferred fantasy scenario is. At that point, the weak link in the chain will not be the cryptography.

GPG doesn't know what the user's requirements are and isn't in a position to judge whether MD5 is strong enough. You suggest that if the tool cannot provide a strong assurance it should not support any checking. But there might be practical attacks against SHA256 being executed right now by NSA cryptographers, just that we don't know about them. It is not possible for GPG or any other program to provide any "assurance" about cryptographic strength now or in the future. Or, to reuse a catchphrase from elsewhere: mechanism, not policy. It is the user's policy decision which ciphers and hash functions to accept as secure enough, and GPG's job to check what it is asked to check. (Of course it would be a good idea to ship GPG with a default policy requiring strong ciphers and key lengths; nobody wants to go back to the bad old days when PGP's default configuration generated crappy keypairs. But in the end it is the user's choice to override that if wanted.)

On the other hand, if what you say is correct, and it should just drop support for hash functions which it can't provide any assurance for, then that would apply just as well to the historic branch of GPG. Support for the older keys should be removed from 1.4 also. Or if there is a reason for 1.4 to exist and a reason for it to continue supporting the older keys, perhaps that's because there is a legitimate need to keep using these older cryptographic mechanisms, for all that they may be breakable by some possible adversary?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 21:58 UTC (Thu) by raven667 (subscriber, #5198) [Link] (18 responses)

I'm not sure I understand what you are advocating here.

> whatever your preferred fantasy scenario is

Just to point out that in a post Snowden world we know that wholesale surveillance, where everyone is subjected to attack by a dedicated well-resourced agencies, is the new normal and not a fantasy.

> isn't in a position to judge whether MD5 is strong enough

Sure we are, MD5 is known to be insufficient for any cryptographic purpose at this time, it is not best practice to use it anymore for anything new, new tools don't need to include it, only tools which may have to deal with legacy data and legacy formats. I linked elsewhere to an instance of someone creating two different JPEG images without visible artifacts that MD5 to the same value, it only cost $0.67 on Amazon with GPU compute.

> there might be practical attacks against SHA256 being executed right now by NSA cryptographers, just that we don't know about them

Sure, anything is possible, but it is not likely and we have no evidence, not even sketchy evidence, that this is the case. Assurance is about probabilities and is never black and white, yes and no, secure or insecure. Or to put it another way, security is a fantasy, technically you are always insecure and we can only argue about how much is acceptable risk.

> if there is a reason for 1.4 to exist and a reason for it to continue supporting the older keys, perhaps that's because there is a legitimate need to keep using these older cryptographic mechanisms

Having a separate supported tool for legacy data and not supporting it in the current tool is a valid migration strategy, and valid software development practice. What is the practical problem with having two different versions of the tool for different eras of cryptographic support?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 22:20 UTC (Thu) by dlang (guest, #313) [Link] (10 responses)

requiring people to install a new package to keep accessing their existing data when they upgrade a package is not a nice way to do things.

Split it into a different binary if you want (if keeping things combined is too ugly), but the new binary should call the old one transparently to the user if it's needed.

And the package should include both by default.

This business of "don't delete version 1.4 when you install 2.1 because you will sometimes need one and sometimes need the other" is user hostile

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 3:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (9 responses)

Versions 1.4 and 2.x are, by design, able to be installed at the same time.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:40 UTC (Fri) by dlang (guest, #313) [Link] (8 responses)

This is still a suboptimal user experience, now the user has to figure this out, and if they just do an upgrade to the new version, they can no longer read their old data.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 10:00 UTC (Fri) by rodgerd (guest, #58896) [Link]

Which is more than a little irritating when one has data retention policies that can go into the decades.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:34 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

expanding on this a bit.

while the two versions can be installed at the same time, they can't both be called gpg, so now the distro (or user) has to pick a name for the old version, it's path, etc and remember it.

Then there is the issue of system automation. You have to change all scripts that could validate or decrypt anything to know about both versions and figure out which version to call.

This is anything but portable and standard from system to system.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:00 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (3 responses)

I just wonder whether automated checking of PGP-2 signatures does no somewhat contradict the original claim that it is not possible to decrypt or verify old data. We are talking about 15 year old data - you still need to check it by a script?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:06 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> We are talking about 15 year old data - you still need to check it by a script?

why not? why should you no longer be able to use automation tools just because the data is old?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:23 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link]

Applying 15 year old patches to at least 15 year old software? If you are forced to use such old and thus buggy software, verification of the patches is not very helpful. But if you think different, there is 1.4.

Also recall that until 2 or 3 years, many people kept an installation of PGP-2 to be able to decrypt their old mail because it was legally not possible for gpg to do that (IDEA patent). Not very different to what GPG 2.1 ask you to do. With the only difference that GPG does this for security reasons.

For the minority of users with these specal needs we spend the time and trouble to keep 1.4 alive and hopefully secure.

GnuPG 2.1.0 "modern" released

Posted Nov 17, 2014 10:30 UTC (Mon) by epa (subscriber, #39769) [Link]

A "script"? No. You want to view these older messages in your email client. What, you don't have older archived mboxes going back decades?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 21:25 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

IIRC (and I'm not 100% sure about this), but the command line interface isn't completely compatible between the two anyways, so having them both be available as 'gpg' wouldn't be suitable anyways.

GnuPG 2.1.0 "modern" released

Posted Nov 15, 2014 10:13 UTC (Sat) by dd9jn (✭ supporter ✭, #4459) [Link]

Right, the PGP-2 command line compatible options

-k[v][v][v][c] [user-id] [keyring]

have been removed from 2.x a long time ago but are still available in 1.4 despite that they are marked as as deprecated since 1999.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 23:15 UTC (Thu) by epa (subscriber, #39769) [Link] (6 responses)

Widespread NSA surveillance - yes. The NSA breaking into your mbox files on disk and somehow changing messages to ones with forged signatures because of some MD5 weakness - no. Whatever the reason to drop support for the older key format, it is not because breaking PGP signatures or encryption with them is even remotely feasible today. (25 years from now it might be different, which is why these older keys should be avoided for new encryption or signing.)

A working attack against PGP, for example to forge the signature on a message, would be a sensational result. That is a long way from generating two JPEG files of random pixels which have the same MD5 hash.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 0:31 UTC (Fri) by dkg (subscriber, #55359) [Link] (5 responses)

I'm not compelled at all by the argument for signature verification -- if you didn't notice whether a given signature on an e-mail was valid when you received it 15 years ago from your peer with a v3 key, it really isn't important that you find out today. And you can still read the signed message without verifications.

There are exceptions here, like people doing software archaeology, who might be interested in signatures of old tarballs (but don't have particular security requirements for their work). Archaeologists can use special tools.

So what about people who have encrypted data that really do need to be able to read their archives? Those folks are probably best off decrypting with specialized tools and re-encrypting.

Most people using GnuPG today do not have old v3 secret keys, and some of those who do have old v3 keys don't have any significant v3-encrypted data. So it's a very small group of users who have the need for v3 decryption, and those users are likely to be people with some level of crypto or software experience at this point.

So we need to weigh the options. We can give all users the rope to hang themselves with old, broken crypto, and ask our already-stretched-thin crypto developers to maintain extra code that they know is too weak to offer strong guarantees. Or we can ask the archaeologists with their legacy sigs and old-crypto-heads with legacy encrypted archives to use specialized tools for their specialized needs.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:42 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

if the signature only matters when it's received, why does it need to be cryptographicaly strong? you want to be able to validate the signature years later if it's something worth signing in the first place.

Also, having a standard practice to decrypt all your data and re-encrypt it means exposing data in it's decrypted state much more frequently than you need to. Not a good security recommendation.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:53 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

Yes, if you do find that the current encryption is too weak the cautious practice would be to encrypt it again - so it is now doubly encrypted and you don't need to churn through all the plaintext.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:30 UTC (Fri) by dlang (guest, #313) [Link]

that would be reasonable, except that they are dropping support for decrypting the inner layer of encryption, so it's not double encrypted, you need to decrypt it to plaintext and then encrypt it agains.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:56 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

What you call an archaeologist is anyone with signed or encrypted messages from twenty years ago (or often less). It is not at all unusual for correspondence to be kept that long - perhaps not all correspondence, but important messages, which are particularly those where cryptography is likely to be used.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:30 UTC (Fri) by dlang (guest, #313) [Link]

don't just think about correspondence, think about signed code dumps/patches