Hacker News Reader

Comment by tptacek | Hacker News Reader

It was on this day in 1991 that Pretty Good Privacy was uploaded to the Internet [... then...] a number of volunteer engineers came forward and we made many improvements. In September 1992 we released PGP 2.0 in ten foreign languages

Fun fact: "We made many improvements" is doing an interesting lift in this paragraph, since PGP 1.0 shipped with a cipher of Zimmerman's own design, Bass-O-Matic, which lived up to its name in part by being demolished by Eli Biham over a lunch. PGP 2.0 introduced IDEA, and, I believe, the first (for the era) cryptographically credible version of PGP; a more fitting anniversary to celebrate, perhaps.

(We've learned quite about about how to engineer cryptography in the ensuing 29 years, and PGP hasn't kept up --- can't, really; so on the 30th anniversary of Bass-Free PGP, we might fittingly celebrate by finally giving PGP a well-earned retirement.)

View on HN

More about this story:

https://crypto.stackexchange.com/questions/61948/what-was-th...

I just downloaded the source code for PGP 1.0 and found BASSLIB.C. 1988!

It's interesting to note that the Bass-O-Matic design apparently came from a Navy contractor (Charlie Merritt). It seems possible that Merritt and the Navy both thought this design was secure; maybe they didn't have clearances to learn others' opinions about it, and only used it for unclassified communications.

What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs.

For package signing: use something in the signify/minisign family.

To encrypt a network transport, use WireGuard.

To protect a web transaction on the wire, TLS 1.3.

For transferring files: use Magic Wormhole.

For backups: use something like Tarsnap or restic.

For messaging: use something that does Signal Protocol.

To protect files at rest, use encrypted DMGs (or your OS's equivalent, like encrypted loop mounts).

To encrypt individual files --- a niche ask --- use Filippo's ungooglable "age".

Thanks! Link to "age", for those who are interested:

https://github.com/FiloSottile/age

Last I looked "age" did not have any sort of recovery utility. It isn't even clear that such a utility is possible (the protocol is poorly documented). A single bit error at the start of the file causes the loss of the entire file. So be careful using it for any sort of thing that might ever require the sort of recovery that bzip2 or lzip provides (gzip has a third party recovery utility).

OpenPGP has excellent recovery properties out of the box BTW...

I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough?

>Failing to decrypt on a single bit error is the literal job definition of authenticated encryption.

Yes, this is an excellent example of where this behaviour is suboptimal. We should not cargo cult authenticated encryption. It has its place but this isn't it.

> Any error you accept is malleability conceded to an attacker.

Sure, but malleability that has a close to zero chance of being a problem. We are talking about static encryption here. You only get one chance at malleability and the user immediately knows something has gone wrong:

    gpg: WARNING: encrypted message has been manipulated!

>Are you complaining that age isn't malleable enough?

Merely pointing out that for the most common use case age is objectively worse than GPG.

I think you are doing a fine job of advocating the position that PGP is the cryptosystem of choice for people who believe authenticated encryption is a cargo cult.

The logic you're applying here about how GPG can warn you if it has employed "recovery properties" to correct "single bit errors" was embraced enthusiastically by the Ruhr team to perform data recovery on other people's PGP-encrypted email messages.

> Sure, but malleability that has a close to zero chance of being a problem.

https://efail.de

https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...

This isn't even a controversy among cryptographers or cryptography engineers.

Efail is an excellent example of how the static encryption of OpenPGP used for encrypted email makes malleability irrelevant. To make the Efail attack against OpenPGP work requires the knowledge of the first 11 bytes/characters of the unencrypted message. The attacker would only get one guess. The recipient by necessity would see the attack message and would immediately know there was something going on. As a result the Efail attack against the malleability of OpenPGP is completely impractical.

Contrast the Efail situation with that of TLS. TLS allows almost unlimited secret trials against its cryptography by an attacker. There have been multiple practical attacks based on such oracles in TLS.

>This isn't even a controversy among cryptographers or cryptography engineers.

I would like to think that there were such people out there that understood that different techniques are applicable to different problems.

the knowledge of the first 11 bytes/characters of the unencrypted message.

You probably know how that worked out for the Enigma.

I am not suggesting that email clients should entirely depend on OpenPGP email inherent resistance to oracle attacks, only pointing out that it exists. Presumably the Enigma operators were not putting their decrypted messages in envelopes before sending them off to their enemies. Efail was primarily a straight up plain text leak.

Plain text attacks come in distinct categories. The block ciphers used in OpenPGP are generally considered to be immune to the sort of plain text attacks used against Enigma.

I think when you're at the point in your argument where the bar you're setting is "immunity to the attacks that broke Enigma", you might as well just concede.

> The attacker would only get one guess

As described in Efail, they don’t need to guess; they know the first 11 bytes with very, very high probability.

I doubt me being able to read a third of your encrypted emails is remotely acceptable to you.

> The recipient […] would see the attack message and would immediately know there was something going on.

That solace is fleeting when it is already too late. The attacker has your decrypted message.

You can just read the Efail paper and see how faulty this argument is. Because PGP treats authenticated ciphers as a "cargo cult", the Efail team could plausibly have broken almost 40% of Facebook's PGP-encrypted password reset mails. Further: they were able to abuse MIME encoding to get multiple guesses per email.

At any rate, none of this is something that anyone would accept from any modern cryptosystem, and the fact that PGP has you so backfooted that you'd feel the need to defend PGP's behavior here is a telling indication. "PGP: it's fine, as long as you don't use it to encrypt password reset emails. But for other emails it's fine, as long as the first 11 bytes of the email aren't guessable." Ok. Good note!

Maybe we should just put 128-bit nonces at the tops of all our emails. That just seems like common sense good engineering practice.

>Further: they were able to abuse MIME encoding to get multiple guesses per email.

The paper did not provide any example of an email client where this would work. I have as of yet not been able to reproduce this. Since there would be no practical reason for such behaviour the assertion requires some sort of proof.

This makes no sense to me.

If I run a file through age, and then run that through a Reed-Solomon encoder, I now have a file that can be decoded even with single bit errors. But I think I also still have authenticated encryption. The cost is that my file takes a bit of extra space.

Am I missing something?

You are not. Of course, the problem is that PGP doesn't get its informal resilience to single-bit errors through error-correcting codes on the ciphertext.

To be clear, OpenPGP does not correct errors. You still end up with corrupted data. It is just that you get back all your good data, no matter where it is in the file.

So you're saying that not only does OpenPGP release unauthenticated plaintext to callers, but it doesn't even implement the feature that takes advantage of it. Good note.

What's crazy about this is that you can get error correction without using insecure 1990s cryptography, simply by forward error correcting your ciphertext. I'm really having a hard time even getting my head around the argument you've managed to devise here.

What exactly is an OpenPGP recovery property? Can you point it out in the RFC?

OpenPGP specifies cipher feed back (CFB) mode[1] for block ciphers (normally AES). CFB has the inherent property that it is self healing in the face of corruption. It does not work in all possible instances of corruption but it works for the normal sort of corruption that is seen with mass storage devices (multiples of 512 bytes). A practical example here[2].

[1] https://datatracker.ietf.org/doc/html/rfc4880#section-13.9

[2] https://articles.59.ca/doku.php?id=pgpfan:agevspgp#encrypted...

I see. You're defining resynchronization of the register during decryption as recovery, not parity checks for recovering corrupted data. Fair enough.

It would be nice if there was a reasonable baseline of key format/management that all these new tools shared though. And I don't mean pgp/gpg keyrings, to be clear, which are cumbersome and error prone and over-complicated for a lot of these needs (I'm still annoyed that `pass` is reliant on gpg for forcing me to deal with a keyring).

I see that `age`, which I hadn't actually heard of before, supports ssh keys and identities which always seemed like a fairly natural baseline to me. Would be nice if more of the command line variety did as well (even if only rsa and/or ed25519 keys).

Why? Why is that good? One of the basic cardinal sins of cryptography is using the same key in more than one context. I don't understand the value of the SSH thing, either.

What is a "context"? I don't want to manage a ton of key files on my desktop computer.

I don't want to use the same key in multiple contexts, but I think some norms around how keys are stored would help build best practices around them.

It would also potentially mean easier to use with hardware tokens, if you could just expect to be able to use something like gpg-agent or ssh-agent or something in between to work with various things.

Fair enough, that's a good answer. Thanks!

Hardware cryptographic storage comes to mind, or simply key management and storage is complex with multiple keys in a lot of different forms.

Which of these do I use to send encrypted messages to darknet vendors based on well-known public keys shared through Reddit etc? This is the number one use case of PGP for me and it doesn't seem to be solved by any of these other tools.

The big problem with those DMGs is that they only work on one OS. This is one thing where PGP encrypted files shine.

I find "age" a bit awkward when it comes to handling private keys. I want to store my private key files encrypted. If it just would accept private key files that have been encrypted with a passphrase it would be almost perfect.

There are ways to work around this [1], but I'm not happy with any of them.

[1] https://news.ycombinator.com/item?id=24378350

Good news, everyone!

https://github.com/FiloSottile/age/commit/d164fef036a2d19280...

It will be in the next release candidate.

How do you feel about 7zip's AES encryption functionality for files or sets of files?

It is maddeningly difficult to simply encrypt a file with interoperable tools. I'm optimistic about age, but it's early days. I understand why people want to use 7z for this. The problem is, if anyone else tries to send you an encrypted zip, and they use something other than 7z, they will likely end up using something even worse than Bass-O-Matic; the zip encryption ecosystem is unbelievably horrible, and it's intractably difficult for ordinary people to know what they're getting. So: long story short, I would tell a client "never, ever use encrypted zips".

I think PGP is fine for encrypting some files. But you should take into consideration that when you encrypt a file it's very likely that some (or all) of the plain text is left behind on the block device. Using full disk encryption (LUKS for example) will give additional protection (so one can't read plain text fragments from the device when it's not "open").

I don’t understand why people want to replace PGP. Of course we can improve the technology but the fact is that security is hard and requires interplay between the humans, processes and technology to work. It’s not enough to rely on just one of those pillars.

There is an illusion in the world of IT that we can solve everything with technology.

Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech.

Happy birthday PGP!

It's funny that you could make literally the same argument about C, especially since so much of the PGP ecosystem relies directly and entirely on software built in C.

> Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech.

What you've got here is pretty much the mirror of the argument you've dismissed a paragraph earlier. Now you're desperate to rely on humans instead.

This makes me think about Snowpiercer, for two reasons. One is that Snowpiercer has this ludicrous conceit about replacing unavailable engine components with humans but the other is that we've really been here with the actual railway trains in the nineteenth century.

There was a pattern. One of these new-fangled railway trains crashes, often killing many people, the company directs public blame toward the driver, who will be portrayed as incompetent, drunk or worse and so fully responsible for the accident. Nothing changes, rinse, repeat. How was this cycle broken?

We did not find some species of super-human train driver, instead we invented technology such as the Absolute Block system, Interlocking railway signals, the Dead Man's Handle. Even apparently trivial technologies like the Driver's Reminder Appliance (it's just a switch!) are still technology.

PGP isn't very good technology. Like one of those early mechanical signals that might seem to indicate "clear" but it's actually just weighed down by snow and frozen in place so that it can't indicate "danger" instead, the way forward isn't "We need to rely on super-humans to compensate for the short-comings of the technology" but "We need a technology that sucks less so the humans don't need to be super-human to succeed".

> PGP isn't very good technology.

What part of PGP precisely? I've read a lot of criticism of PGP but they were either focused on a specific (catastrophic) implementation such as GNUPG, or were really skeptical of usage by non-technical humans.

I know quite a few people doing PGP email with Thunderbird and they're pretty happy with it. It's also very convenient that their GNOME-based Tails operating system has PGP sig verification enabled as context menu entry in the file manager, same for encryption/decryption.

Basically, once you know what public/private keys are, you've got all you need for secure communications. Is that a bad thing? My only HUGE criticism of PGP is with the key servers. It's getting better now with WKD, OpenPGPCA, etc.. I'm really excited about the Sequoia project. From their blog/docs it appears all my criticisms of PGP are being addressed.

When PGP was invented, a bunch of things we are now quite sure how to do either were experimental or hadn't been discovered. In some of those cases you can retro-fit to PGP, so e.g. you can use a nice elliptic curve signing primitive instead of RSA, you can do AES instead of IDEA. So far not too bad.

But then in some cases what we became quite sure about is that PGP's principles/ assumptions are themselves wrong. For example, PGP is pretty sure a message ought to have a digital signature from the sender so you know who it's from. But that's wrong, now you're helping the recipient prove to everybody else what you sent them. That doesn't sound like "pretty good privacy" at all. If instead we do message integrity correctly we can assure the recipient that you wrote it, but since they could have forged that assurance they don't have proof you wrote it which they could show to anybody else. They could tell others what it says, but they could just as well make up any rumours they want.

The worst of these problems is the Web of Trust. The Web of Trust can't work. It might work if everybody you know is a cryptographer and everybody they know is a cryptographer and so on. But it can't work in real life, and often in describing it people make revealing mistakes.

Let me quote somebody else making such a mistake (not on HN) and then I'll reproduce part of my response to their mistake in answer:

"How much do you trust guy #53 of 120 you met at FOSDEM? Do you remember how well you checked his ID?"

I am 100% certain my mother is my mother, but I wouldn't trust her as far as I can throw her. And this is where the WoT breaks down. Your trust metric must reflect your confidence that these people will do their part correctly in the WoT, but even conscientious users often don't understand how to do their part correctly, so realistically almost everybody's "trust" indication for almost everybody should be zero. At which point it's not a "web" it's just a bunch of unconnected points.

The other points in this thread recommending modern, context-specific cryptography tools are very valid, however if you're set on PGP; Sequoia[1] is a new(ish) OpenPGP library written from the ground up in Rust.

1: https://sequoia-pgp.org/

Sequoia is fine work, and running less C code is a good thing, so if you have to use PGP (sorry) then use Sequoia. But note that the PGP ecosystem is hopelessly mired in GPG, and the problems go beyond C code --- Sequoia, for instance, is (AFAIK) the first popular implementation of AEAD crypto for GPG, but AEAD doesn't interoperate with GPG.

https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/...

I still use PGP 1.0 as all of the scanners that check for stuff can't recognize any of it, and it slides through. It's more of payload thing

Reply on news.ycombinator.com