PGP problem

Original author: Latacora
  • Transfer
Crypto engineers have been shouting about PGP shortcomings for decades . When ordinary developers hear this, they are extremely surprised. How, PGP is no good? Why, then, is it advised to use it? The answer is, PGP is really no good, and should never be recommended to anyone. He must disappear.

As you will soon see, PGP has a lot of problems. If you do not go into details, the main reason is that the program was developed in the 90s, before the advent of serious modern cryptography. No competent crypto engineer today will develop a system in this form and will not tolerate most of its defects in any other system. Serious cryptographers basically abandoned PGP and no longer spend time on it (with some notable exceptions) Therefore, the well-known problems in PGP remain unresolved for more than ten years.

Two small notes. Firstly, the article was written for engineers, and not for lawyers and activists. Secondly, “PGP” can mean a lot of things, from the OpenPGP standard to the reference implementation in GnuPG. We use the term “PGP” for all of this.

Problems


Absurd complexity


For reasons that no one understands now, PGP is package-based. The PGP message (in the .asc file) is an archive of typed packages. There are at least eight different ways to encode the length of a packet, depending on whether you use the “new” or “old” format packets. Packets of the “new format” like BER have a variable length (try writing a PGP implementation, and the ASN.1 coding standard will seem sweet to you). Packages may have subpackages. Some package options overlap with each other. The last attack on the key server is due to the fact that due to this irresponsible format, GnuPG key parsing accidentally leaves in quadratic time .

And this is just an encoding. The real system is much more complicated. There are keys and plug. Key identifiers, key servers, and key signatures. Keys are only for signature and only for encryption. Numerous keychains. Certificate Revocation. Three different compression formats. That we have not yet reached the support of smart cards.

Swiss army knife design


If you get lost in the forest and ... I don’t know, for example, you need to trim the lapels on jeans - yes, it’s very convenient that you have scissors on your knife. But for serious work, no one will regularly use such scissors.

A Swiss army knife does a ton of things, and everything is bad. PGP is a very mediocre tool for signing documents; it encrypts relatively badly with passwords and works very poorly with public keys. PGP is not particularly good for secure file transfers. This is a clumsy way to sign packages. It is not very good for protecting backups. This is an extremely dangerous way to exchange secure messages.

Back in the era of MC Hammer, when PGP appeared, “encryption” was a special thing in itself; there was one tool for sending files, backups, for encrypting and signing files. Modern cryptography doesn’t work like that, we need specialized tools. Cryptography for secure messaging is different from cryptography for backing up or signing packages.

Backward compatibility swamp


PGP precedes modern cryptography and is very outdated during this time. If you're lucky, your GnuPG will by default have a 2048-bit RSA key, a 64-bit CAST5 cipher in CFB and an OpenPGP MDC checksum (about which later). If encryption is done with a password rather than a public key, the OpenPGP protocol will establish the S2K key generation algorithm for PGP. To put it mildly, these are not the primitives that a crypto engineer will choose for a modern system.

We have learned a lot since the nerd Steve Urkel decorated the prime time on ABC. We learned that encrypted texts should be authenticated (and CFB mode avoided), that 64-bit block ciphers are bad, that RSA is not perfect, that a combination of compression and encryption is dangerous, and that KDFs must be strictly generated both in time and in memory.

No matter what the OpenPGP RFC says, you probably don’t do anything from this list if you use PGP, and it’s impossible to tell when the recommendations will begin to be implemented. Take AEAD ciphers: Sequoia PGP in Rust defaulted to AES-EAX AEAD mode. It's great. But now no one can read their messages, because most versions of PGP do not know what EAX mode is, and this is not very cool. In every bad cryptosystem, the end result is an RFC extension that supports elliptic curves or AEAD, so that its supporters can shout in the forums that they support modern cryptography. RFC does not matter: only real settings. We invented authenticated encryption 20 years ago, and PGP will soon retire; enough excuses.

Either you have backward compatibility with the program of the 90s, or you have good cryptography; you cannot get both .

Nasty UX


It’s hard to formulate it better than Ted Unangst:

A few years ago, a PGP usability study was conducted, in which a group of technical experts was placed in a room with a computer and asked to configure PGP. Two hours later, none of them had yet responded.

If you need your own empirical data to confirm this, here is an experiment you can do: find a lawyer who is far from computers and help him install Signal by phone. He will probably cope without hysteria. Now try to do this with PGP.

Long-term secrets


PGP asks users to keep the root key tied to their identity almost forever. Key generation and exchange is cumbersome with these “key signing parties” and the “trust network”, where the keys depend on other keys.

Long-term keys are almost always uncomfortable . If you continue to use the key, it eventually becomes public. From the point of view of a competent system design, it is necessary to minimize damage and ensure that the user does not hesitate for a second when thinking about generating a new key, if there are at least some concerns about the security of the current one.

PGP fans will immediately answer: "That's why you need to keep the keys on Yubikey." But according to a quick rough estimate, almost no one in the world uses expensive Yubikeys, and this is unlikely to change in the future (we can barely deploy U2F, and those keys are disposable). We cannot accept bad cryptosystems just to make Unix nerds more comfortable playing with their toys.

Broken authentication


More information about the archaic primitives of PGP: back in 2000, the OpenPGP working group realized that it was necessary to authenticate encrypted text and that PGP signatures did not. Therefore, OpenPGP invented the MDC system : PGP messages with MDC attach the plaintext SHA-1 to the plaintext itself, which is then encrypted (as usual) in CFB mode.

If you're wondering how PGP handles this when modern systems use relatively complex AEAD schemes (because they can't just attach SHA-1 to plaintext), then this is a good question. How would you describe this cartoon? PGP MDC can be cleared of messages - it is encoded in such a way that it is quite simple to cut off the last 22 bytes of the ciphertext. To maintain backward compatibility with unsafe old messages, PGP introduced a new type of package that signals the need for MDC verification. If you use the wrong type, then MDC is not checked. Even if you do, the new SEIP packet format is fairly close to the unsafe SE format, which could potentially trick the recipient into lowering the cipher; Trevor Perrin has reduced SEIP to just 16 bits of security .

Finally, even if everything goes right, the PGP reference implementation will produce unauthenticated plaintext on request, even if the MDC does not match .

Inconsistent Identities


PGP is an application, a set of integrations with other applications, and a file format, and a social network, and a subculture.

PGP puts forward the concept of cryptographic identity. You create a key, save it in a keychain, print its fingerprint on a business card and publish it on the key server. You sign someone else's keys. They, in turn, may or may not rely on your signatures to verify other keys. Some people try to meet with other PGP users in person to exchange keys and more securely register in this “trust network”. Others organize key signing parties. If you imagine all this activity, it becomes clear how difficult it is for dedicated PGP fans to switch to new technologies.

But this whole system does not work in practice. Neither a trust network with key signatures, nor key servers, nor parties. Ordinary people will trust everything that looks like a PGP key, no matter where it came from - how can they not trust, even if it is difficult for an expert to formulate how to evaluate the key? Experts do not trust keys that they did not personally receive. Everyone else relies on centralized key distribution services. PGP key distribution mechanisms are a circus.

Metadata leaks


For a second, forget about the email debacle (we'll come back to this later). PGP itself can leak metadata. In normal use, messages are directly associated with key identifiers that are associated with the user identifier throughout the PGP trust network. In addition, a fairly large proportion of PGP users use key servers that themselves issue to the network which PGP users exchange messages with each other.

No direct secrecy


Case in point: cryptography for secure messaging requires forward secrecy. Direct secrecy means that if an attacker receives your key, he will still not be able to read previous messages. In modern cryptography, we assume that the adversary writes everything to infinite storage. Opponents of PGP include world governments. Of course, some of them do this. Against serious opponents, hacking cryptography without direct secrecy is only a matter of time.

To ensure direct secrecy in practice, you usually keep two secret keys: a short-term session key and a long-term trusted key. The session key is ephemeral (usually a DH exchange product), and the trusted key signs it, so that the person in the middle cannot use his own key. Theoretically, direct secrecy can be realized with PGP tools. Of course, almost no one does this.

Ax keys


The OpenBSD signify public key is a Base64 string short enough to fit in the middle of a sentence in an email; a private key that is not an exchange format is just a string or so. And the PGP public key is a gigantic Base64 document; if you used them often, you are probably already used to sticking them in an attachment rather than pasting them in messages so as not to damage them. The signify key is generated by the advanced Ed25519 algorithm, and PGP by the weaker RSA.

You might think that it does not matter, but it is important; orders of magnitude more people use SSH and manage SSH keys than PGP. SSH keys are trivial to handle; PGP - no.

Matching


PGP supports ElGamal, RSA, NIST p-curves, Brainpool, Curve25519, SHA-1, SHA-2, RIPEMD160, IDEA, 3DES, CAST5, AES. This is not a complete list of what PGP supports.

If in the last 20 years we have learned three important things about cryptography, at least two of them, it is that reconciliation and compatibility are evil. As a rule, the shortcomings of cryptosystems appear in implementations, rather than primitives, and expansive cryptocompatibility increases the number of implementations. Modern protocols, such as TLS 1.3, seek to get rid of backward compatibility with archaisms like RSA, rather than add it. Newer systems only support one set of primitives and a simple version number. If one of these primitives fails, you get rid of this version and immediately drop the entire old protocol.

If we are not lucky and after 20 years people will still use PGP, it will remain the only reason why the CAST5 standard is applied at least somewhere. We cannot say this more clearly, and we need to repeat it many times: either you have backward compatibility with the program of the 90s, or you have good cryptography; you cannot get both.

Trash code


The de facto standard implementation of PGP is GnuPG. This program is not very neatly written. There is an extensive code base in C - language with duplication of functionality (for example, in the description of a recent denial of service attack on SKS parsing it is said that it has several key parsers) with a long CVE track record, ranging from memory corruption to cryptographic attacks through third-party channels. Sometimes it was possible to remove authentication from messages, but GnuPG did not notice this. You could feed him the keys without the correct fingerprint. In 2018, the Efail vulnerability was caused by the fact that GnuPG provided unauthenticated plaintext upon request. GnuPG is not good.

GnuPG is both the reference implementation for PGP and the foundation for most other PGP cryptography integration tools. He is not going anywhere. Relying on PGP means relying on GPG.

The answers


To convince a person to give up PGP, it is important to explain to him that PGP has nothing to replace, and that’s normal . An alternative tool depends on the task.

Conversations


Use Signal. Or Wire, or WhatsApp, or some other secure messenger based on the Signal protocol.

Modern secure messengers are designed specifically for messaging. They use confidential authentication handshakes, cancellation messages, cryptographic ratchets(ratchets), which issue a key for each messaging, and, of course, modern encryption primitives. Messengers are trivially easy to use, no fuss with keys and subkeys. If you use Signal, you get even more: you get a system so paranoid about saving private metadata from servers that it even tunnels Giphy search queries to avoid traffic analysis attacks, and until recently it did not even support user profiles.

Email Encryption


Do not do this.

Email is not secure . Even with PGP, this is plain text by default, that is, even if you do everything correctly, some completely reasonable recipient of the letter, doing absolutely reasonable things, will necessarily quote the plain text of your encrypted message to someone else in CC (we don’t know the email user PGP mail, which did not come across this). There is no direct secrecy in the PGP email. Email metadata, including the subject (which is literally the content of the message), is always transmitted in clear text.

If you need another reason, read the Efail vulnerability article . GnuPG community that failed with Efail disclosurecritically criticizes this article, but it was accepted at Usenix Security (one of the best academic centers for software security), as well as at the Black Hat USA conference (the leading software security conference). This is one of the best cryptographic attacks in the last five years - and a pretty destructive bomb against the PGP ecosystem. As you will see from the article, S / MIME is no better.

It will never be fixed. To make really secure email, you have to tunnel another protocol via email (you will still be vulnerable to an attack with traffic analysis). That's just the point, why pretend?

Encrypting email is clicking trouble. Encouraging users to encrypt email if something threatens them is exceptional negligence. Anyone who tells you about the security of email communication with PGP encryption puts their strange preferences above your security.

Sending files


Use the Magic Wormhole . Wormhole clients use one-time key authentication with password authentication (PAKE) to encrypt files. It is easy (at least for nerds), safe and fun: everyone to whom we showed the “mole hole” immediately began to pass through it all the files in a row, as we do.

Someone immediately launches the installer for Windows on Rust or Go, this is too cool a program to not use it.

If you talk to lawyers, not engineers, Signal does a great job of file transfer. For error reporting, publish the Signal number, not the PGP key.

Backup encryption


Use Tarsnap. Colin will explain how Tarsnap is optimized for protecting backups . Or indeed, take any other backup encryption tool; it won't be as good as Tarsnap, but it will still be better than PGP.

Need offline backups? Use disk image encryption; it is built into modern versions of Windows, Linux, and macOS. Full disk encryption is not very good, but it does an excellent job of this task, and it is simpler and safer than PGP.

Package signature


Use Signify / Minisign. Ted Unangst will tell you everything . This tool is used to sign packages in OpenBSD. It is very simple and applies modern signatures. Frank Denis Minisign (one of the libsodium developers) implements the same design on Windows and macOS; It has bindings to Go, Rust, Python, Javascript, and .NET; It is even compatible with Signify.

Application data encryption


Use libsodium : this is a universal library with an interface in which it is difficult to make a mistake, and you do not need a binary to work.

File encryption


This is really a problem. If you have / not / backup, / not / archive for long-term offline storage, / not / file encryption for transfer and / not / encryption of virtual disks that you mount / unmount as needed, then there is not a good tool to encrypt files. For other purposes, Filippo Walsorda is developing an age tool , it seems promising, but not yet ready.

Hopefully this is a pretty narrow use case. We work in the field of software security and process confidential data, including error reports (another very common case when they shout “We need PGP!”), But almost never use PGP.

Also popular now: