GnuPG 2.1.0 "modern" released [LWN.net]

GnuPG 2.1.0 "modern" released

Posted Nov 9, 2014 21:41 UTC (Sun) by epa (subscriber, #39769)
In reply to: GnuPG 2.1.0 "modern" released by dkg
Parent article: GnuPG 2.1.0 "modern" released

The linked reasons for why not to use v3 keys are not terribly convincing. Or rather, they are fine as reasons not to sign and encrypt new documents with such keys, or generate new keys in this format; they are poor reasons to justify why existing data using such keys should no longer be supported. Key ids and key signatures do not matter much - fine, drop support for importing old keys by id if that can be spoofed, but the case that matters is when you already have the full key and want to use it. Only the weakness of MD5 is a convincing reason, but still it applies much more to why you should not use MD5 from now onwards, much less as an argument that existing MD5 signatures are somehow breakable in practice (they are not).

But really the question is one of principle. We know that over time ciphers and hashes will become less secure, so what is used today will be deprecated in the future. So if you encrypt a document today, will it still be decryptable in the future? If the package manager in your distribution pushes out a new version of GPG (and that will happen, unless those packaging it are alert enough to spot the backwards incompatibility and split it off as a separate package name) then existing files can no longer be decrypted or verified. It is as if gzip stopped reading old format .gz files. OK for a major version upgrade, perhaps, but not something to happen regularly, even if there are very good reasons not to compress anything more in that format.

Now the GPG developers have a solution: maintaining a historical release (1.4) which supports the old key formats. That works, as long as some wrapper can be written to invoke the correct GPG version, and this wrapper is updated in tandem with GPG itself.

to post comments

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 7:50 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (30 responses)

MD5 is an cornerstone of the v3 packets format (PGP-2) and that is a major problem. MD5 is broken and thus all v3 keys should be considered broken. If there is still data encrypted to an PGP-2 key it should be re-encrypted in the the process of the regular migration to a new medium. If you don't do that you will have to maintain a copy of GPG or PGP-2 in your box with the spare 5.25 floppy drives.

If it comes to reading old mail - re-encrypt it. If that is such important to many people, i wonder why no easy mail re-encrypt tool exists? In fact you don't even need to re-encrypt it, it is sufficient to add another encryption key.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 8:09 UTC (Thu) by dlang (guest, #313) [Link] (29 responses)

so how would mail from me to you sitting in your inbox get re-encrypted?

you don't have access to my key, and I don't have access to your inbox.

or are you saying that anything that was signed by an old key should be considered unsigned at this point?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 9:00 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (28 responses)

You encrypted to my old public key and thus I can I can decrypt it with my old secret key and encrypt it again to my current public key.

Right, signed mails should be considered unsigned. We can't claim that SHA-1 is broken (which it is currently not) to an extend that Mozilla will soon reject TLS connections made with SHA-1 and at the same time keep on using and trusting MD5 which is known to be weak for 20 years, has easy to create collisions for 8 years, and pre-image attacks are known for 3 or 4 years.

(and yes, I can't understand why ssh still defaults to MD5 fingerprints)

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 10:01 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (1 responses)

The known pre-image attack for MD5 is only marginally better than brute force. It's a theoretical rather than practical attack, nobody has or could obtain the resources to even try it once as a proof of concept, let alone weaponise it.

I agree that we should migrate off MD5, and SHA-1 too, but migrating off something is not quite the same as it being broken. People have been saying MD5 will "soon" be broken for about a decade now and it's still standing. When the tornado warning siren sounds, you should seek shelter, but it would be a mistake to therefore conclude that each time the siren sounds a tornado hits.

If you have a message sent to you in 1996 with an MD5 MAC, you can in many ways be even _more_ confident in 2014 that it's genuine than you could when you received it in 1996. Because if somebody broke MD5 _before_ 1996 they have so far kept it secret for 18 years, which is quite remarkable and thus very unlikely.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 11:23 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Okay. A MAC is very different from a plain hash and even HMAC-MD5 is still believed to be safe. OpenPGP does not use a MAC, though.

GnuPG 2.1.0 "modern" released

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

but even the pre-image attacks don't result in a document that looks like a reasonable e-mail, or other human readable document (even a computer interpreted binary needs a bunch of 'junk' thrown in to create a match)

So while it doesn't result in a mathematically 'guaranteed[*]' signature, something signed by an old key that looks reasonable still has a very high probability of being what was initially signed.

As for encryption, how does being able to generate a new document that has the same hash as the old one make it possible to see what was in the old document?

I agree with the earlier poster, it's worth preventing these old keys from being used to sign/encrypt new stuff, but it doesn't make sense to prevent them from being used to access existing data (or validate the signature of the old data)

As I said before, it's just not possible to re-sign every document that was created, and even for encryption, if the encrypted version of the document is in the hands of the bad guy, re-encrypting your copy of it will achieve absolutely nothing in terms of preventing the bad guy from decrypting it.

So no, those documents should not be thrown away and their signatures treated as being worthless.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 11:20 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Okay, okay,

what we see here is the usual problem of practical cryptography: We have to find some middle ground between those who use the software for every days purpose and the more paranoid geeks, known crypto gurus, and policy requirements. That is not easy and with my pragmatic user hat on I agree to your concerns. OTOH, I have to defend the use of such "insecure" practise from the complains of the latter group. See for example https://bugs.debian.org/739424 .

Instead of trying to fix flaws related to the use of PGP-2 keys, 2.1.0 simply kicks out all support and I feel now much safer not to keep on maintaining all these little workarounds for PGP-2.

To say it with Rick: We always have 1.4.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:55 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> but even the pre-image attacks don't result in a document that looks like a reasonable e-mail, or other human readable document (even a computer interpreted binary needs a bunch of 'junk' thrown in to create a match)

While you would probably notice in an email it is demonstrated that you can create JPEGs with the same MD5 and it's not even hard anymore.

http://natmchugh.blogspot.co.uk/2014/10/how-i-created-two...

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 19:54 UTC (Thu) by dlang (guest, #313) [Link]

so that means that when you can throw in a huge amount of essentially random data without the user noticing, then signatures involving md5 are not that useful

But if you limit the problem space to something that is human readable and makes sense (in a human or programming language without large blobs), then it becomes a MUCH harder problem.

And if you are trying to alter what someone said to make it seem like they actually said something else (as opposed to just vandalizing something, for which deleting the data is just as effective, and not protected by any encryption/signing), then you are even more contrained.

If you have signatures on code, then before any weakness in the hash is significant you need to be able to replace it with new code that will compile, and doesn't scream "something wrong" when a human looks at it.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:01 UTC (Thu) by epa (subscriber, #39769) [Link] (21 responses)

I think you are failing to draw a distinction between "algorithm X has known weaknesses which may, at some future date, lead to a possible way to forge signatures or break encryption" - which is currently true of MD5 - and "algorithm X is so weak it is broken today, and here is some proof of concept code which forges a signature or cracks an encrypted message".

We all agree that MD5 is less than ideal because there have been some successful research efforts to find weaknesses in it. We all agree that at some point in the future it is likely that further flaws will be found, and/or advances in CPU power will make a brute force attack possible using the existing known weaknesses.

What doesn't make sense is to deduce from that that existing MD5 signatures (or keys which use MD5, etc) are so broken they are not worth supporting for existing documents. Existing signed and encrypted messages exist in many people's inboxes. For better or worse electronic mail and saved mailboxes are used as a permanent archive and record of what people said. Some of those messages will be from people who are no longer alive, or who for whatever other reason refuse to re-sign older messages with whatever is today's recommended system.

If you feel that "signed mails should be considered unsigned" then I invite you to take a message signed with an older key and produce a forgery with the same signature. (No, not a block of random data but an even remotely plausible forged message.)

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:26 UTC (Thu) by dkg (subscriber, #55359) [Link] (20 responses)

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.

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