When almost all implementation of PGP are broken, can we say PGP is broken?

Is PGP broken? Or the plugins that make PGP easier to use email, that are rendering HTML, or those perhaps what is really broken?

Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time.

The MAC of a PGP message is the SHA-1 of its plaintext appended to the message.

There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP is broken but we already knew that".

>Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time.

Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email technologies for well over a decade, but at the same time the cryptography field has never offered an upgrade. Instead it's always been "completely give up on the concept of email (which in no way needs to be insecure) for these modern hip non-federated often proprietary clunky slow kitchen sink instant messenger things instead". To which the answer has and continues to be "no".

Maybe we live in a world where the creation and upgrading of a technology like email is no longer feasible and that's just how it is. If so though I foresee email as it is existing into the foreseeable future, and in turn it'll be useful to have some sort of crypto bolted on top, as a marginal improvement vs entirely plain text. Hopefully there will be enough security oxygen that OpenPGP could at least modernize the foundations a little even if it meant some breaking changes to old implementations.

No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.

>No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging.

That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.

>Don't send secrets over email

Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.

>replace email with this thing that requires a phone number and is not like email

No.

>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.

No.

The problem with emails is that you have to deal with a thousand different clients implementing things differently. There is no win there.

Your argument is "everybody on the planet including all corporations and governments should instantly abandon email for an instant messenger thing instead of which there are many and no federation" which is a bullshit argument and you damn well know it. FFS, how often over the decades in security have we had to make do with highly suboptimal solutions that were the lesser of evils? When did you of all people become a head-and-feet-in-the-clouds pure idealist?

It's like coming into a global warming discussion and demanding everyone forgo personalized point-to-point mechanized transportation because of inherent inefficiencies vs mass transport. Or saying IRC is shit and therefor everyone should move to mailing lists or whatever. It's worse then even suggesting moving to something that's still "groups in 'rooms' with instant messaging" which at least is a technical feature match, it's suggesting dropping an entire UX. It's not happening. Path dependency is a thing, and so are specific desirable features that can be used alongside other channels for different tasks.

I gave reasons. You're the one implying everyone who doesn't dump a straight forward, desirable UX global standard for a bunch of silo'd different formats are idiots/old fogies/don't care about security/privacy at all. The very simple fact that even accepting dumping that UX for messaging service you still couldn't simply say "switch to this only" but had to list a couple of things further highlights the whole problem. Is every individual and organization on the planet also supposed to support every single secure messenger? If not what is the winner vs the losers tptacek? Saying I had no argument but"no" and ignoring everything else is insulting sure, but I also think it's not a helpful attitude to making the world a more secure place period.

Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them. What will we demand next, forward secrecy? We should climb down from our ivory towers.

>Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them.

That's not what you're demanding. You're demanding the end to a UX. That's entirely orthogonal to security, and my whole point is that's very different from pushing people to go from an insecure version of a UX to a more secure version of a UX (or at least a strict superset of that UX). It's straight forward to argue "don't use HTTP, use HTTPS", or "don't use SMS, use {secure messenger}"[1], or "don't use POP, use POPS or IMAPS" or even "don't use an 8 character password that is the name of your dog on a website, use something random and preferably a password manager".

But that's not your argument.

1. Though again, the basic fact that I can't just tell anyone in the world, on any device at all, what {secure messenger} vs "SMS" should be is inherently suboptimal though less so.

> not leak the contents of our messages to anyone who can intercept them

Already a thing, next?

> forward secrecy

There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.

Forward secrecy doesn't make sense in the context of email? Please, go on.

If you know of a way of ensuring forward secrecy without a response from the recipient, I'm all ears. Considering that NaCl's crypto_box() interface doesn't provide forward secrecy, I feel somewhat safe in believing it's flat out impossible.

Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.

If you want that handshake for email, I don't know how to do that without giving the long term keys to the mail server, which in most cases is operated by a third party that reads your emails for a living. I'd love to have a solution for that, but I don't believe there is any.

Simply put, forward secrecy doesn't make much sense in the context of email.

I don't understand any part of this argument. What wouldn't make sense would be for crypto_box() to provide forward secrecy, since it isn't a messaging protocol, but rather a simple primitive for authenticated public key encryption --- a low-level building block from which you build protocols.

It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport. But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".

Thomas, you're frightening me. I'm talking about relatively basic stuff here. I almost hope I'm wrong.

The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online.

If the recipient is not online, as is expected of asynchronous communication applications such as email, an intermediate server has to hold the message for him. At this point, you either give up on the handshake, or hand over the secret key to the server.

Good luck setting up a trustworthy server. Even if I hosted my stuff at home, I might not be too keen on leaving it on where it could be examined by forensics while I am away. It's not bad, but it's not perfect either. And forget about third party servers, they are untrusted by default. I'd rather give up forward secrecy instead, and keep my private key on an encrypted file on my personal laptop.

So we can't have that hand shake. The protocol has to look like: (i) Alice and Bob know of each other's long term public keys. (ii) Alice encrypts then send a message to Bob. (iii) Bob receives then decrypt that message.

If I knew of a protocol that followed those constraints and still preserves forward secrecy, you could be damn sure I'd put it in Monocypher—one less thing the user could screw up. (Actually, I'd love to be proven wrong there, it would improve my crypto library right away.)

> It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport.

You'd still have to give the long term keys to a machine that is online when the message is sent. For asynchronous protocol, this means always online, and we're back to square one.

> But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".

Are you implying that forward secrecy is required for "security"?

All of the first part of your message constitutes much of the rationale behind Signal Protocol, which is asynchronous, does not assume participants are online at the same time, and does not involve you handing secret keys to a server. But, of course, Signal isn't the only way to accomplish forward secrecy.

Am I "implying" that forward secrecy is required for message security? No, I'm saying it directly.

> All of the first part of your message constitutes much of the rationale behind Signal Protocol

OK, I'll look it up, thanks. Though I suspect I already have (the 3-DH the Wikipedia mentions looks familiar, I suspect it is X3DH). Better than nothing, but not quite perfect.

Yeah right. "How can we communicate this piece of secret info?" - "Oh, that's simple. You just need to a) switch to your mobile device, if you don't have one, buy one. If you don't have mobile phone line, buy that one too while you're at it b) install a software you've never heard about before - trust me, it's ok because nobody ever had any trouble with software downloaded from internet c) send your private information - namely, your private phone number - to it d) send your private information to me e) receive my private information about my phone number - trust me, it doesn't have to be communicated securely f) get secret information sent to your mobile device g) figure out how to get this information to your desktop device now securely, it's not my problem anymore, figure it out h) figure out how to remove this information from your private mobile device. You see, much simpler than sending an email!"

It woulds still be great to get some sort of protocol that will work over email. This is still the de-facto way of communication. If we can secure it, it would be a massive win. Much like the wide-spread use of HTTPS over HTTP was a massive win.

Why would that be a good thing? You'd still be left with a system that leaks immense amounts of metadata, which is often all government adversaries really care about, where the majority of the installed base isn't encrypted and you have to interoperate, and the vast majority of users gets access to messages through a web browser and so is hamstrung on secure delivery of encryption in the first place.

Just stop using email to deliver secrets.

>Just stop using email to deliver secrets.

At the least I'm not sure this is legally feasible under ERISA electronic delivery requirements, to name a single one amongst a host of other often incredibly complex regulations. It might be ok under the UETA, but either way that wouldn't be my call.

I am 100% sure that it wouldn't be ok with coworkers, customers, and in turn bosses, so demanding to cease all usage of email would get me fired. I mean, even entirely plain text email isn't sufficient to get anyone to stop using it to deliver secrets. It's been a real improvement just to have the MUA<>Server connection be encrypted, and even that is probably still not universal!

I think the GP's desire is not email per se, but rather an open and federated protocol like email so we aren't dependent on a single commercial vendor. I'm not really sure how practical that is since it's really hard to get broad adoption of a new protocol on today's internet.

Sure, email leaks meta-data.

But at its core, the promise of pgp/gpg is the promise of encrypted and authenticated file transfer.

The file might come from ftp, samba/cifs, Dropbox/Google drive/etc, from tape or HD backup - or come attached to an email.

It may come from yourself, or from a friend.

But the promise is that between the encryption and signing - and the verification and decryption - the file remain the same. The zip file is as (Un)safe to extract, the font as (Un)safe to render - the installer or the executable as (Un)safe.

If you have (authenticated) file encryption, you have encrypted email.

If you want to use authenticated file encryption as a secure messaging platform, you should probably invest in a more sane format for your plaintext file than email. And a better wrapping transport than email.

The fundamental problems with email+pgp as a secure messaging platform isn't pgp alone - but the intersection of email-the-format, email-the-protocol mixed with the mail user agents and their 80s trusting file handling (ok, that's unfair to the 80s, we're still too trusting when it comes to files in general and transclusion in particular).

In short, I don't think we should give up all of pgp as such (open, secure, authenticated file encryption and Web of trust).

But it's probably true that newer protocols are better for "real-time" messaging, and perhaps usenet is better for hold-and-forward.

[ed: I'd love to hear some current informed discussion about: https://saltpack.org/ mentioned in this discussion here. From the previous hn discussion it seems reasonable; a sane format (message pack), authenticated encryption primitives - but I worry a bit about public key handling - is there Web of trust/certificate support - and if so, is it sane? I'm not saying pgp/gpg wot is sane. But neither is ssh (certs) in practice. I'd much prefer wot - were for some applications I could choose arbitrary key/certs as authorative CAs and give out short-lived "certs" (signed public keys with valid from-to).]

> a system that leaks immense amounts of metadata

Doesn't Signal require you to publish your actual phone number, which reveals your RL identity in the network pretty much completely controlled by government?

No.

Explain? I Googled it and it seems that Signal still doesn’t support having an account that isn’t tied to a phone number. Some of the results suggest working around the limitation by obtaining a phone number just for Signal from third parties, but that’s not a particularly reasonable alternative.

This article explains how to create a second phone number, for usage for Signal. Which confirms my assertion that you need phone number, and makes your statement of "no" completely false. Among options offered:

The desk phone at your office.

A free Google Voice phone number, if you live in the United States (this is what I do).

Any phone number from any online calling service, like Skype.

A cheap pre-paid SIM card for a few dollars a month (and temporarily put it on your phone to register your second Signal number).

Twilio, a cloud service that allows developers to write software that makes and receives phone calls and SMS messages.

Obviously, each of those still requires registration within government-controlled phone network, and additionally also may require you to entrust your security to a third party - such as your employer, Google, Microsoft or Twilio. So in fact, you refutation of my assertion "you need to publish a phone number" is "you can have two phone numbers". This is not serious.

As an added bonus, some of these creative solutions also make MITM-ing the whole scheme as trivial as "our corporate phone tree has changed, please use new number 1-555-666-666 to contact me from now on". You have no way to verify it, nobody knows how corporate trees and phone prefixes look like. And of course if the person is fired or reassigned or leaves the job (which never happens!), their account is now under control of some unknown third person.

Signal doesn't entrust security to carriers. Messages are sent E2E encrypted to the registered device over the internet. If someone MitMs a device, the safety numbers would not match on either end.

Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.

My experience of Signal is that people don't reliably follow up on safety number changes, yet keep using it in a MITM-vulnerable way. Including myself, honestly, because people change or reset phones frequently. Is your experience different?

At least with GPG I can factory reset all of my computers and phones and not have to re-establish trust if I take the right steps to preserve the secret key information.

Even if I don't preserve that correctly, people change computers less often than phones.

On the other hand, I'll admit that my GPG key is newer than my Signal number (which I've owned for 15 years), due to upgrading crypto algorithms.

It isn't. I rarely send sensitive messages, however, so I feel that some surveillance potential is acceptable, to save time and effort. The few times where I did, I first verified both ends.

I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)

I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.

It entrusts the identity to carriers. What use of having perfect peer-to-peer security if you can't be sure who you are talking to? So you will send the data to Eve in a perfectly secure way, while thinking you're talking to Bob - and that's better than Eve breaking the encryption? I say it's much less work for Eve - instead of employing vast resources to exploit a tiny vulnerability in encryption, she would just need to take over a phone number. And if she works for the government, it's not even a hard thing to do.

Again, you can be sure, by comparing the safety numbers. It's the same as comparing SSH or GPG key fingerprints. If someone else masquerades as Bob, the numbers won't match. See section III-D3, key fingerprint verification: https://www.ieee-security.org/TC/SP2015/papers-archived/6949...

That would be true if people routinely verified fingerprints of their contacts. I don't think it happens more often than any other commonly ignored security precautions. Also, what happens if the phone is lost/damaged/replaced with a newer model? I assume new key and thus new fingerprint?

Signal, WhatsApp, Matrix et al. show notifications when the participant’s device keys change. You’re right that most users don’t verify. The opportunity for detection or prevention of common forms of surveillance is better than none at all.

Not ready to recommend Riot/Matrix?

I do not recommend it, but it's very probably better than PGP email.

Why don't you recommend it?

Wouldn't a bunch of secure messenger drama be fun right now?

Sorry, I'm just not nearly as familiar with the intricacies and differences between them, know that you definitely know your stuff on crypto, and always thought Matrix seemed cool/interesting.

At some point, all the recent work that tptacek mentioned on encrypted messengers is going to percolate up into email.

Taking something like megolm [1] and running it over SMTP is such an obvious answer that, eventually, somebody will give it a go. Until then, we get to keep having this argument on the internet every few weeks...

[1] https://git.matrix.org/git/olm/about/docs/megolm.rst

It does exist, but has approximately zero users

https://saltpack.org/

No PFS, though

FWIW thank you for that, even without PFS and no adoption it's at least interesting to see a more recent effort to work within the flawed existing email system but do a bit better then PGP. Like OpenPGP or S/MIME themselves I guess, simply made with something beyond 90s era crypto experience. Although even for something at that stage I'm surprised they don't have anything I can see about what the identities they use are like in the FAQ at least. That's a significant practical difference in PGP and S/MIME for example.

Now that I think about it there is also a modest effort to simply enhance the UI of the whole deal through transparent embedding vs as an attachment. I think modest efforts of that nature that are evolutionary vs revolutionary around existing installed base will like it or not continue to serve an important practical role.

> Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now

Do you mean that gpg is broken for non email use cases as well? Eg. encrypting tarball with backups using gpg and then storing it on some cloud service?

What would be the most sensible steps forward for the PGP maintainers? Is this a rewrite, or can they iterate though and make incremental improvements around the flaws that have been discussed over the past decade?

A bit of both. We can fix a few bits in compatible ways, but it's not a reliable long term solution.

Long term, we really need an upgrade that breaks compatibility with old unfixable clients

>Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now;

No they don't. Also PGP works just fine. It could use some improvements, but it's doing well.

In this particular case, some implementations of one of the use cases are broken. This is completely incorrect to say PGP is broken as it implies all (or most) use cases and not only particular scenario.

But in MOV SS/POP SS case we don't say Intel chips are broken, we fix the OSes and the docs.

Why not both? Documentation can also be faulty