PGP Is Dead? (2018) | Hacker News Reader

PGP Is Dead? (2018)

wired.co.uk

31 pointsgrobbie50 comments

> Of course, there are potential problems with allowing private companies to hold the keys to all of your sensitive conversations. But, these projects are generally less vulnerable than PGP because they are independent, says Green.

> “When something goes wrong with WhatsApp, WhatsApp fixes it,” he says. “When something goes wrong in the amorphous PGP community, no one puts their hand up to fix it.

This is some whacky reasoning, explaining away the questionable trust of for-profit entities holding your keys by saying "at least they're segregated islands of questionable moral fibre!"

My distrust of WhatsApp and the like is far less about fixable vulnerabilities, and far more about their underlying business models.

With raw tech like PGP, this isn't a concern - I don't have to trust a key server not to decrypt my data and sell it to advertisers _because they theoretically can't_

---

Overall this article seems to play pretty fast and loose with argument logic, seems a little weasel-wordy from my (very) brief skim. Are they saying PGP is dead because the UX sucks, or because there are vulnerabilities?

All feels very "seatbelts are uncomfortable, but modern cars are super safe - just trust that other drivers won't be idiots"

The general argument is that open protocols tend to be stagnant while private ones are not, and that is true.

Private protocols can iterate faster, have a vested financial interest to not lose customers, are often not required to be as backwards compatible which further slows updates and they can tightly integrate from backend to user. Open protocols always tend to be disjointed, i.e Email + PGP whereas something like Signal is just integrated because it's all under control of a single entity.

In reality, and this is evidenced by user choice, that level of integration is important. It's why 99.9% of users are on Twitter, and not on Mastodon.

> have a vested financial interest to not lose customers

This is just as satisfiable - if not more so - with slick marketing and platitudes than with actual security.

It sounds like it is amazing we are all still using the IP stack to communicate.

> Private protocols can iterate faster, ... like Signal is just integrated because it's all under control of a single entity.

The speed of iteration is of little comfort when what they are iterating is against the wishes of the users who are captive to their network effects.[0]

> It's why 99.9% of users are on Twitter, and not on Mastodon.

I dare say that Twitter also generates 1000 times more revenue than all Mastodon instances combined, so all that's proven here is that having more money lets you make a more addictive website. That's not necessarily something we should be celebrating, especially as users are paying with their privacy and the stability of their societies.

[0] https://www.stephendiehl.com/blog/signal.html

I've read through, it seems they are claiming it's for PGP to die because of someone else's bugs such as Outlook etc. And as per claiming the bug needs to be triggered by crafted html. So here come two more questions: 1. How does such html get injected into the email in the first place? 2. Why would someone ever use html instead of plain text for important emails that needs to be encrypted?

A great deal of effort is being taken to dissuade people from RSA4096 and PGP. But we do know from the Snowden leaks that system is(was) secure against the NSA if properly implemented. "This destroys the RSA cryptosystem" no doubt is driving adoption of Curve25519 and Signal.

I think we need to talk about layering more. There's no shortage of compute cycles today. Each message should go through encapsulated rounds of encryption, preserving the older standards until it can be definitively proven they are broken, which has not been the case with RSA. At least one of those layers should be multivariate or lattice post quantum scheme. https://github.com/polysome/vane

"Let's ditch open protocol X that has worked well for decades, in favour or closed protocol Y. Because of some transient issue with open protocol X, it's now time for open protocol X to die"

Heard that before?

It's as if if your doctor told you it's now time for you to die because you caught a cold.

>Let's ditch open protocol X that has worked well for decades

To be fair, I really can't put PGP in the category of "open protocol X that has worked well for decades"[1]. I'd welcome a closed protocol that actually works over an "open" one that's been functionally broken for years.

[1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

The problem is that email is store-and-forward, and there's no standard for MUAs to independently interact and perform key exchanges via PGP or anything, so end-to-end encrypted email will always be a much worse experience than end-to-end encrypted IM.

Also, the heterogeneous MUA world, and the fact that users expect to be able to search their email even if encrypted, just makes end-to-end encrypted email a really tough proposition.

I could see something like OTR+PGP for email that could work, but the MUAs would have to get updates, and MUAs are "a solved problem". There's just no real work ongoing on MUAs.

https://signal.org/docs/specifications/x3dh/

The Signal protocol, which is the one all the big service providers are licensing for the instant messaging encryption part of their service offering, is actually supposed to be designed for store and forward scenarios because messages can be sent when users are offline.

It is founded on Diffie-Hellman, a key exchange algorithm developed in the 1970s (the stuff in the article about PGP being developed "before we really knew anything about cryptography" seems bogus at best) that has very much managed to weather well.

I understood that elliptic curve Diffie-Hellman has been widely adopted primarily because it's just a compact way to represent the large numbers needed in order to make the key exchange process robust (I think the second coordinate of the curve can be represented with just a single bit, so more efficient than other approaches), but perhaps I am wrong or misguided on that.

Anyway, regardless - I don't trust the claims of perfect forward secrecy in services like WhatsApp and Signal for a moment - any more than I believe that Crypto AG sold devices that really worked. Perhaps the protocol implements PFS. But does WhatsApp really implement the protocol?

Besides, I recall reading that running the Unix command `strings` over the popular Signal messaging app revealed a static encryption key hardcoded into the application binary, which was used to encrypt all the attachments downloaded to the phone. Gaining access to the phone meant easily reading the messages (using Android accessibility features to "read them out loud") and with the hardcoded secret, easily decrypting the attachment storage too.

I've never read of a police force anywhere in the world actually shutting down citizen access to WhatsApp, at least not unless they're non-allies or otherwise considered hostile to the US. But I have heard of modified, PGP enabled BlackBerrys being seized by police forces all over the world because they really can't break them.

So my working method, fwiw: if I have something private to say that I do not wish to be snooped upon, I do send it over Signal or WhatsApp, but I say it with PGP, and then I delete it and ask the other party to do the same.

The weakest point of any crypto is the implementation itself.

We used to say that key management was the weakest link, but now I think the implementation itself is the weakest link.

Alice and Bob simply cannot defeat Mallory when Mallory is responsible for the implementation of the crypto that Alice and Bob are using to defeat Mallory.

But most users can't implement their own crypto. And the few users that could would stick out like sore thumbs. And they would still have key management headaches.

Basically, crypto can work to protect against criminals, but not against the state. That was always true anyways: the state can apply legal and nominally-illegal rubber hose cryptanalysis (i.e., they can beat you with a rubber hose, real or metaphorical, to get you to give up your secrets).

The mandatory response to that mandatory link is the article "The PGP Problem: A Critique".[0]

[0] https://articles.59.ca/doku.php?id=pgpfan:tpp

Isn't the Signal Protocol an open protocol?

https://signal.org/docs/ and https://en.wikipedia.org/wiki/Signal_Protocol#Implementation...

The platform (smartphone) is a proprietary, insecure black box. Lately, vendors are brining client side scanning to phones too.

With PGP, you can take your message anywhere, to any OS, client software and with any encryption key and algorithm you like, to encrypt it.

Yes, PGP is dead but not because of any of the reasons this article points out.

It's dead for a very simple reason: it's really hard to find active PGP/GPG keyservers.

Fedora keyserver? Dead

Debian keyserver? Dead

openSUSE keyserver? Dead

SKS keyserver pool? Dead

keys.gnupg.net? Dead

keys.openpgp.org? Half-dead (HKPS access not working, it seems only web is working) etc

Very few keyservers are still online and some of then don't sync with the others (e. g. keyserver.pgp.com).

> keys.openpgp.org? Half-dead (HKPS access not working, it seems only web is working) etc

Can you be more specific? HKPS looks fine from here, and we've had no downtimes on our monitoring.

[zxspectrum@zxspectrum ~]$ gpg --refresh-keys

gpg: refreshing 204 keys from hkps://keys.openpgp.org

gpg: keyserver refresh failed: No keyserver available

This is likely an issue with GnuPG, respectively its dirmngr component. This can typically be fixed via `killall dirmngr`. See also https://dev.gnupg.org/T4513

For a simple check, those two commands perform exactly the same http request: > curl https://keys.openpgp.org/pks/lookup?op=get&options=mr&search... > gpg --keyserver hkps://keys.openpgp.org --recv-keys F357AA1A5B1FA42CFD9FE52A9FF2194CC09A61E8

https://keyserver.ubuntu.com/

Still going strong.

What an obvious attack piece. Throwing PGP under the bus for some failures at a higher level. Give me a break.

> But the biggest problem with PGP is how difficult it is for people to use simply. "It’s a real pain," says Green. "There’s key management – you have to use it in your existing email client, and then you have to download keys, and then there’s this whole third issue of making sure they’re the right keys."

How is this PGP's fault? The computing world has had 24 years to catch up with the standard, and frankly it does everything listed here out of the box on Linux. Microsoft, Apple and Google have all been dragging their feet in the sand when it comes to actually implementing it, so the onus really falls on them as far as I can tell.

PGP is still Pretty Good Privacy: not perfect by any means, but a considerable step up from plaintext. Maybe there are credible threats to it's security, but most people reading this will probably be dead before it's implemented.

> you have to use it in your existing email client, and then you have to download keys, and then there’s this whole third issue of making sure they’re the right keys.

If you use Thunderbird as your email client, then it will download the right keys for you automatically.[0]

Actually it's two clicks to use the WKD support to download the key (assuming your correspondent's email provider supports that, as ProtonMail does[1]) or the keys are already downloaded if they are included as an attachment or as a header (which is the case if your correspondent is using a client that supports Autocrypt[2]).

As with other E2E encrypted systems, you should check these keys(' fingerprints) out of band, otherwise your security only follows the TOFU model, but this is still a huge improvement over non-PGP email and doesn't require any special understanding of cryptography.

[0] https://support.mozilla.org/en-US/kb/openpgp-thunderbird-how...

[1] https://protonmail.com/blog/security-updates-2019/

[2] https://autocrypt.org/

Wait, wait, wait. ProtonMail only supports WKD lookups for desktop. I've had an open request for years to their support team to implement WKD lookups on mobile. As ProtonMail is the only PGP email provider with any mass traction, at this point it's just a middle finger to people who prefer to control their own selfhosted mailservers.

I can't expect any PM user is going to be able to send me PGP encrypted mail when many emails start from a mobile device.

I was curious about this problem, and found that the pull request for "Implement WKD" (in the web app) was merged[0] in December 2019, and there is a bug report[1] from October 2020 complaining that the Android app can't look up (some) WKD keys. That bug was last updated in November 2020 and is still open.

[0] https://github.com/ProtonMail/proton-contacts/pull/338

[1] https://github.com/ProtonMail/proton-mail-android/issues/44

Well Thunderbird just went to a 'roll-your-own' version of pgp, so seems it is an issue with the mail clients instead of pgp itself. And I expect Apple and Outlook use their own thing. Plus this seems specific to html mail.

So sending mail via mutt as text should still work fine with gnugp.

Also use proprietary Signal ? Really ? Not me!

Be interested in various easy alternatives for encrypted messaging that non tech people will use. I've never had much luck with getting other people to use PGP, so many clients I have dealt with in the past have been all too quick to send sensitive information in plain text emails. The problem is, this info is often not super critical but not something you'd share with people, and generally the attitude is "No ones going to hack this, why would they? it will be fine ". Then people become super sloppy, they send this kind of info into support desk systems, "group" emails, etc. Mostly these days I try to force sensitive information exchanges to phone calls / 7z with passwords exchanged on a call. Hard to get people to care about this.

If you want encrypted instant messaging, I'd recommend the Matrix ecosystem, using the Element apps.[0]

For an email-based protocol, I would suggest Delta Chat[1], which is backwards compatible with existing email accounts, and follows the Autocrypt approach to PGP[2].

[0] https://element.io/

[1] https://delta.chat/en/

[2] https://autocrypt.org/

Old article is old

May 2018 specifically

Has anything changed? PGP is literally thirty years old now, and I'm not aware of any significant changes to either the protocol or to the support landscape.

> PGP is literally thirty years old now, and I'm not aware of any significant changes

sounds like a good thing to me

That's a bad thing. PGP has some really awful usability problems which have never been addressed. The paper "Why Johnny Can't Encrypt" described some of these issues in 1999, and a series of followups ("Why Johnny Still Can't Encrypt", "Why Johnny Still, Still Can't Encrypt"...) have come out over the years confirming that it still hasn't improved.

PGP is a protocol, not a client. It should be up to clients to make it easy to use. You can setup PGP in Thunderbird in one minute https://support.mozilla.org/en-US/kb/openpgp-thunderbird-how...

Edit: maybe what seems easy to me can seem hard to someone else. Not sure if I'm having a bias here.

Someone should carry out a study where they test whether people can create a ProtonMail account and send an email from it (with a control group trying to do the same using Gmail). They could title the resulting research paper "Why Johnny Can Now Encrypt".

I've heard fairly compelling arguments for why ProtonMail isn't a good choice if you want privacy due to where your keys are saved.

And it still involves some significant trade-offs in terms of functionality: Potentially worse (spam) filtering and no full-text search unless you keep a full local copy of your mails around (which is rather unreasonable on a phone and impossible with webmail).

And those trade-offs are more or less fundamental if you want to access your mail from multiple devices, but at the same time don't want to trust your server to handle decrypted mails.

All depends on your threat model. I would never expect to receive sensitive information via email in 2021 when there are protocols like Matrix available. Even my bank and utility providers only send me email notifications telling me to login to their platform to view sensitive information. At this point, other than select business communications, email has been relegated to a two-way notification system for most people.

Sure, I send a lot of emails, but likewise, if I had anything worth keeping private, I certainly wouldn't be sending it in an email, even an encrypted one.

I don't know of any tests specifically for ProtonMail, but "Why Johnny Still, Still Can't Encrypt" tested the usability of another in-browser PGP interface and found it lacking.

Funny. I was incidentally reading Snowden leaks recently, published by a German media. As is known, NSA put PGP in the category “catastrophic,” often responding to requests with “no decrypt available,”

But, interestingly, it said members of intelligence agency themselves are using PGP to secure their communication!

Anyways, this is not PGP vs non-PGP debate. Rather, whether you manage your key or let a company manage the key for you. At that point, it doesn’t matter much if you use OpenSSL, PGP, etc to encrypt your data.

And PGP offers a secure and convenient way to encrypt your information on your computer from command line.

This is wild. PGP Encrypted Email woes does not make PGP dead. Wild.

Note that this is a 2018 flame-bait article of Wired quality.

Just because it's quicker and easier to pop it in the microwave, doesn't mean that it's healthier than a home cooked meal.

In this case, not enough people know/care how to cook.

Doesn't mean it's unhealthier either. How you cook something and how healthy it is are not related in any way.

Home cooked cake is less healthy than a microwaved scrambled eggs.

> Users have a public key and a private key – senders use the former to encrypt messages, which can only be decoded by someone who has access to the latter.

Kind of nitpicky, but I'll be cautious taking clickbaity claims like "PGP is dead" from someone who makes such a mistake in their first paragraph.

It's more like they're sloppy than that they've made a mistake.

The session key would be encrypted with the recipient's public key so that they (and hopefully only they) can decrypt it and then decrypt the message encrypted with the session key. The sender would use the recipient's public key.

That's my point. Someone with such little attention to detail that they're this sloppy has no business dictating to the world anything really. Either you don't know what you're talking about or you don't proof read before you publish. Either way don't tell me what's dead and what's not.

PGP is also a disaster in non-email scenarios. Many times I've had to implement systems that receive pgp encrypted files and then decrypt them and load them somewhere else. To this day there are no good libraries for this. There's either GPGMe, or shelling out to the gpg command line tool. Both options are terrible.

https://sequoia-pgp.org/

Reply on news.ycombinator.com