> “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"
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.
This is just as satisfiable - if not more so - with slick marketing and platitudes than with actual security.
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.
> 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.
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
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.
To be fair, I really can't put PGP in the category of "open protocol X that has worked well for decades". I'd welcome a closed protocol that actually works over an "open" one that's been functionally broken for years.
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.
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.
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).
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.
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.openpgp.org? Half-dead (HKPS access not working, it seems only web is working)
Very few keyservers are still online and some of then don't sync with the others (e. g. keyserver.pgp.com).
Can you be more specific? HKPS looks fine from here, and we've had no downtimes on our monitoring.
gpg: refreshing 204 keys from hkps://keys.openpgp.org
gpg: keyserver refresh failed: No keyserver available
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
Still going strong.
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.
If you use Thunderbird as your email client, then it will download the right keys for you automatically.
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) 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).
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.
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.
So sending mail via mutt as text should still work fine with gnugp.
Also use proprietary Signal ? Really ? Not me!
For an email-based protocol, I would suggest Delta Chat, which is backwards compatible with existing email accounts, and follows the Autocrypt approach to PGP.
May 2018 specifically
sounds like a good thing to me
Edit: maybe what seems easy to me can seem hard to someone else. Not sure if I'm having a bias here.
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.
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.
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.
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.
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.