> In 2013, an article on "Zimmermann's Law" quoted Phil Zimmermann as saying "The natural flow of technology tends to move in the direction of making surveillance easier"
"
Surveillance capitalism is a concept in political economics which denotes the widespread collection and commodification of personal data by corporations. This phenomenon is distinct from government surveillance, although the two can be mutually reinforcing.
"
The only plausible way of processing that amount of traffic is a massive Orwellian application of automated voice recognition technology to sift through it all, searching for interesting keywords or searching for a particular speaker's voice.
There's a good idea in PGP, and a very bad one. The good idea --- and PGP genuinely deserves credit here --- is end-user, consumer-facing strong cryptography tools. That's now universally accepted and has been for decades. The bad idea is a tool with PGP's design, of "cryptographic jack-of-all-trades". PGP's design has aged like milk, and PGP itself is a security liability in almost every system that hosts it.
We don't need to keep elaborating or re-litigating the same discussion. The PGP idea of "one tool to rule them all" is a terrible cryptography design, and the world is better off the sooner we stop trying to make it work.
By what I saw, there wasn't really anything anyone would care about in https://gpg.fail/ . The GnuPG problem actually declined to respond to some of them.
I guess the code base has really become a bit messy over time with all that parsing and different crypto algorithms. But the attack surface can be significantly reduced by using sq or even better stateless sqop.
Secure messaging is its own (increasingly well-defined) cryptographic problem. Group secure messaging is a distinct problem with its own cryptography. Backups are their own problem with their own constraints. Package signatures are their own problem.
There isn't one cryptosystem that does all these things. For messaging you want a carefully-defined notion of forward secrecy and post-compromise recovery, along with a careful decision about repudiation/non-repudation (1990s cryptography doctrine would suggest you just always want nonrepudiabilty, which turns out to be disastrous for privacy). For backup, you want deduplication and content addressing. For packages, you want transparency logs. You almost never want long-lived keys, but you often want identify binding.
PGP solves basically none of these problems, and offers instead a 1998 API (I'm not kidding, I thought about what year to pin it at) to basic cryptography primitives.
Another thing is also that email itself was not designed with encryption in mind and because it is decentralized and backwards-compatible it is hard to enforce new rules (everyone should use PGP).
But PGP is useful if both sender and receiver agree to use PGP.
> But PGP is useful if both sender and receiver agree to use PGP.
Anecdotally: this works until you add a third person who responds to the thread in plain text, with everything threaded beneath. Or when you do that by accident.
Applied cryptographers will tell you to use Signal or any other E2EE chat.
Signal's has buildable source code on the client side and all. However, the server code is closed source and the developers have made disquieting changes like uploading most users' contact lists to the server protected only by Intel SGX that is known to have vulnerabilities exploitable by a nation-scale actor.
The point of E2EE is that you don't need to trust the server that you're talking through. A secure E2EE scheme is secure in the presence of an actively malicious server.
I think SGX is a red herring in this context. You can find it risky or not, but it's (1) not material to Signal's E2EE property, and (2) materially better than email, which sends all contact metadata in plaintext, regardless of whether you try and encrypt your message bodies. Bringing it up in this context seems like a category error.
Is this accounting for the fact that they kill people based on metadata? More technically complex and unreliable protocols such as SimpleX attempt to also protect the metadata.
The point is that if the comparison point is PGP-encrypted email, which has no protection for any metadata and passes it on the wire in the clear, raising concerns about Signal’s metadata protections makes no sense.
PGP the packet formats, PGP the tool(s), OpenPGP the specs, GnuPG the tool, GnuPG the library; or any of the other libraries? Web of Trust? All of it? None of the above?
Any time this topic comes up, here and elsewhere, I find that most discussions revolve around different understandings and misunderstandings what people mean when they say “PGP”, and rarely lead to anything beyond that. - no this is PGP no you’re wrong that is PGP and so on and on…
All of those things are liabilities (I read them carefully and mentally checked them off one by one; I'm not just being rhetorical). I wrote a sibling comment going into more detail, but happy to answer questions.
Well, gpg2 is an implementation of openpgp and is GnuPG the tool correct? So are you saying that when I `gpg2 --symmetric myfile` I'm doing something harmful rather than useful?
The expectation is that anybody who ends up with the encrypted copy would have an impossible time trying to decrypt it without, I don't know, millions of dollars worth of compute per year for decades to throw at it or something like that.
The packet format is awful, full of complexity, backwards compatibility mess, and serious security problems.
The spec is pretty awful in that a lot of the complexity is due to keeping compatibility with things that are a terrible idea. And also in that the general concept of a long lived key turned out to be a bad one.
The library or lack thereof IMO cripped PGP/GPG back when it was relevant. It's nigh impossible to make tooling for it, or it was until Sequoia showed up, which was extremely late. Things like doing stats on keys, or doing anything but what the binary wants to do were terribly painful until Sequoia.
The Web of Trust was an interesting idea for a while, but failed to transition to the modern internet.
By the time you fix all the things what remains looks nothing like PGP, so it amounts to "all of it is bad".
PGP is special to me, I was a beta user when Phil uploaded it to some Colorado BBSes, way back when. He even made time to talk to teenage me about it on the phone.
What's crazy is when it was concieved, we didn't have trusted strong cryptographic primitives. We did have DES but it wasn't trusted. We did have some of these crazy ideas that we all would have "secrets" and you might put those secrets encrypted on a disk in a vault and you'd not even want the feds to get them. Now we have all sorts of much more vetted crypto primitives, but the idea of actual secrets you'd keep in cold storage is largely dead. You're spot on that modern use cases need different APIs and tools and specialized solutions.
Can you elaborate? I know of commercial softwares that use it still where only the softer has the private key. Seems to work pretty well, but this is slightly out of my normal scope.
The biggest issue of using PGP was using PGP. You were pretty nerdy to be on the internet back then, but even then using PGP was beyond what the majority of people wanted to do. Exchanging keys was problematic. Writing text in one app, encrypting in another app, copying encrypted back to an email was just tiresome.
I'm still glad that it existed as its mere existence seems to have pushed things in the right direction as far as protecting everyone's ability to use encryption if they chose. It just never became the panacea it was envisioned to be.
There were (are? it's been a while) many PGP users on the various darkweb markets. It was great fun teaching people to use it and actually having a community to use it with.
It was pretty awkward to later emerge as the PGP expert at work. I was at that time a bit shy about explaining how I got so comfortable with it.
The fundamental idea of technology such as PGP is that the percentage of stuff worth finding for the authorities needs to be really low. Ie. an incredible amount of "legitimate" innocent traffic needs to be flowing through the technology.
Otherwise, anyone who is using it at all will get court ordered and then, with our current system, you just lose.
Tor solves this by making traffic entirely homogenous such that any "it could be anyone" and by making nodes extraordinarily easy to host (such that any nerd can just leave one running 24/7). Even so there are way too few nodes.
But PGP-over-email is way too metadata leaky, and if you're doing anything that actually has a threat model, you need PGP-over-email to be itself common.
Even today, you still need an external program to your email app to enable encrypted messages with in the email app. With that, the number of encrypted emails will be extremely low relatively. Even looking at Tor, the amount of users is still much lower than the internet in general. To the point, I doubt a very high amount of traffic is "regular" traffic to raise the noise floor.
It's easy to explain. "I use PGP for my personal notes (symmetric) and for e-mailing my security conscious friends (public-key)". That's sufficient and not awkward.
Yes but that explanation doesn't help you teach people how to use it in an adversarial context. Then they're just following arbitrary rules set down by privacy nerds for seemingly arbitrary reasons.
One big usability issue these days is that PGP identities come in the form of a file. Lots of people don't have the concept of that anymore.
Dunno that things have gotten much better over the years. End to end encryption is still fairly unusable to most. I think that rather than spending so much time on the cryptography we should instead work on a E2EE usability standard. Having everyone doing their own thing with respect to usability is not working out.
ASCII armored exports suitable for plain text copying and pasting and inclusion in other documents and messages seem to be the norm for sharing. Keys are referred to by keyid or email. To the key database, files seem more like an implementation detail.
It provides the tools necessary to implement a simpler workflow.
The term E2EE has been subverted. Apps like WhatsApp claiming to be E2EE, but only if you actually enable it, so that people think they are being encrypted when they are not does not help. ProtonMail falls into this as well where allowing email to non-encrypted addresses means there is no encryption. It's obvious to some, but not so for the majority. Very few people read the caveats that WhatsApp and ProtonMail provide.
WhatsApp doesn't have any option to enable/disable encryption for standard messages that I can see. Business chat messages are not encrypted and neither are backups (by default) but if Alice messages Bob on a fresh WhatsApp install, the message is E2EE (as far as I know). Is that incorrect?
To be honest: I keep hearing that PGP was / is difficult to use. That couldn‘t be further from the truth - but somehow it has become an urban myth. From the very first versions that I used on my first Mac up to GPG Mail or Proton Mail I never encountered any significant difficulties and could successfully exchange messages with my peers - both in business and private contexts.
I once had a chat with a security professor who had decided to try to get his group to use encrypted email for all of their communications. And they just couldn't get mailing lists working right with encrypted email.
In general, a session/thread ephemeral key pair is exchanged with the participants, and only each users private origin signing validates each sender sections. Since the signatures are passively checked, it does not need redone after each append operation.
Thus, participants are pooled under 1 time constrained key exchange, participants sections origins are signed/time-stamped, and the ciphertext expires on a schedule.
Why? so at some future time side-channel key exfiltration can't be used to data mine the entire history of past tapped conversations/ciphertext. Even if a private signing key is stolen, it is difficult to rebuild the lost ephemeral key session.
My eyes glazed over reading that. I feel like 30 years of internet has proven one thing: the simplest solution always wins. PGP is many things, but simple and obvious are not among them.
Please, enlighten me on how you used PGP where calling it hard to use is so far from the truth. ProtonMail only works if you send messages to another ProtonMail user. It does not protect you when you email someone else.
> ProtonMail only works if you send messages to another ProtonMail user.
Your wording is not entirely accurate.
ProtonMail works perfectly well with external PGP. You can import third-party keys and IIRC it also supports WKD.
So its not "only another ProtonMail user".
IN ADDITION .... you can also send an encrypted, password protected message to a non-Proton Mail email address. The recipient can read it in the browser: https://proton.me/support/password-protected-emails
Your use of ProtonMail+PGP is not how people expect ProtonMail to work when it is claimed to be encrypted email. ProtonMail+PGP is no different than GMail+PGP or AOL+PGP or FastMail+PGP or $coolNameMail+PGP. So what's your point?
Anything+PGP can be encrypted. You still have to use PGP which means creating public/private key pairs, store them correctly, and understand when to use the public key and when to use the private key. You still then need to know how to exchange keys in a trustworthy manner, but that's after you convince someone else to do all of that on their end as well.
What GP likely means is that a Protonmail user can exchange encrypted emails with a non-Protonmail user without doing anything except importing the non-Protonmail user's keys once.
This could allow a single technical user with an elaborate PGP key and email setup to convince his or her social circle (or at least email circle) to switch to Protonmail and follow a set of (comparatively) simple steps to get Proton to recognize the key to their non-Proton address.
Thereby having PGP-encrypted conversations with users who don't know how PGP works, but followed their friends' instructions to use a slightly different webmail interface. Meanwhile the technical user can use a smartcard, a self-hosted email server, or other madness that a normal user would never tolerate.
At least the versions I remember had a really bad UX for marking keys as trusted.
The correct operation for (even locally) marking "this key belongs to person X" is signing the key. Marking it as "trusted" indicates "this key is a CA that can create statements who other keys belong to", but it's easier to find/"understand".
So if you haven't first studied the details of the security model and terminology, you just start increasing the trust level on the key of your communication partner until the warnings go away, not realizing that by doing this, you've made that key a CA and the reason the warnings disappeared is because you now trust the self-signature (in addition to all other signatures the key issued).
If we assume that the threshold of what is "difficult" is for example 1) installing a desktop application, or even running a deskop OS.
2) Running an email provider other than what you are already doing (gmail, hotmail, yahoo mail, ...), or switching email providers
3) Copying and pasting text or using files.
This was perhaps a viable thing to do for users in 2005 because if you were on the internet, chances are you at least had a desktop computer, and if you used email chances are you already had to struggle with an email client.
But now? Anything that isn't as easy as installing an app on your device (a device that isn't a full computer) is "difficult".
It's not that it's harder today, it's that everything else is easier (Like telegram/signal and other privacy-minded services), and that there are now 6 billion internet users and most never used a computer and never will.
I don't see how. You just type "gpg -e -r receipient@domain.com filename.txt". It doesn't get much simpler than that. It's not like you are using ffmpeg, imagemagick, or other programs with a hundred switches in it.
Also PGP/GnuPG is not only for email. I encrypt and decrypt hundreds and hundreds of payloads per day, programmatically between trusted and untrusted networks.
And it is mandatory for each employee to upload their public key to our keystore so that we can deliver private information to them securely over Slack, Teams, or other communication channels.
> You just type "gpg -e -r receipient@domain.com filename.txt".
I assure you it is not that simple.
For example, I'm a HN user, developer since 30 years. I know that you referred to what's known as a "terminal" or "shell" here, but that's already way WAY too difficult for 99.9% of users.
And even in my terminal I can assure you it won't work: "'gpg' is not recognized as an internal or external command, operable program or batch file."
I could install it. It would be a right pain though. and it doesn't help if the recipient of my email can't install it without me sending a long list of instructions!
Meanwhile my dad had zero problems installing signal. There's a difference to how easy it gets.
Tell me you're a nerd without telling me you're a nerd. Maybe you've moved the goalposts to "it's easy for tech dorks" vs "it's a total pain in the arse for your mom to use'. If the goal is to have encrypted email everywhere, running anything in via command line is out. If you can't recognize that, then you're clearly just trolling
I used it for a little while and Turnpike email software from the UKs Demon Internet integrated it pretty well.
The problem was only one other person I knew actually used it, it didn't really have a justifiable use for most people.
I did use the encrypted mountable drives for a while, that worked very well. I since moved to TrueCrypt and now onto Vercrypt and haven't used a PGP product for probably over 15 years.
Shame really but it just didn't get enough traction.
There's a lot of negativity around pgp, but I actually like the fact that you see the raw ciphertext as opposed to everything happening in the background.
I also like the portability of openpgp.js its pretty versatile in my opinion.
Agree, we use OpenPGP.js in our web projects. It's great for combining it with server-side GnuPG.
It used to be more of a concern without TLS, but now it's reasonably secure to use.
We use it for the user sessions, allowing the client to own their session and identity.
The browser generates the keypair and signs each post and login challenge, so the private key never leaves the client. The server only stores the public key (as a plaintext file in git) and verifies signatures with GnuPG, which means there's no password hash in the database to leak, and the identity is just a fingerprint anyone can audit. Using two independent implementations (OpenPGP.js on the client, GnuPG on the server) is a nice bonus.
> In 2013, an article on "Zimmermann's Law" quoted Phil Zimmermann as saying "The natural flow of technology tends to move in the direction of making surveillance easier"
The precise term is Surveillance capitalism.
" Surveillance capitalism is a concept in political economics which denotes the widespread collection and commodification of personal data by corporations. This phenomenon is distinct from government surveillance, although the two can be mutually reinforcing. "
https://en.wikipedia.org/wiki/Surveillance_capitalism
Welp.
I remember joking with a professor that he should not use PGP for email privacy because it would make his content more of a target.
That one turned out to be true…
https://www.propublica.org/article/the-nsas-secret-campaign-...
A well-intentioned ideal from a bygone era.
Good ideas demand to be free. =3
There's a good idea in PGP, and a very bad one. The good idea --- and PGP genuinely deserves credit here --- is end-user, consumer-facing strong cryptography tools. That's now universally accepted and has been for decades. The bad idea is a tool with PGP's design, of "cryptographic jack-of-all-trades". PGP's design has aged like milk, and PGP itself is a security liability in almost every system that hosts it.
>PGP itself is a security liability in almost every system that hosts it.
Elaborate
https://gpg.fail/
https://www.latacora.com/blog/2019/07/16/the-pgp-problem
Recommendations: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
We don't need to keep elaborating or re-litigating the same discussion. The PGP idea of "one tool to rule them all" is a terrible cryptography design, and the world is better off the sooner we stop trying to make it work.
Obligatory response to "The PGP Problem":
* https://articles.59.ca/doku.php?id=pgpfan:tpp
By what I saw, there wasn't really anything anyone would care about in https://gpg.fail/ . The GnuPG problem actually declined to respond to some of them.
I guess the code base has really become a bit messy over time with all that parsing and different crypto algorithms. But the attack surface can be significantly reduced by using sq or even better stateless sqop.
Secure messaging is its own (increasingly well-defined) cryptographic problem. Group secure messaging is a distinct problem with its own cryptography. Backups are their own problem with their own constraints. Package signatures are their own problem.
There isn't one cryptosystem that does all these things. For messaging you want a carefully-defined notion of forward secrecy and post-compromise recovery, along with a careful decision about repudiation/non-repudation (1990s cryptography doctrine would suggest you just always want nonrepudiabilty, which turns out to be disastrous for privacy). For backup, you want deduplication and content addressing. For packages, you want transparency logs. You almost never want long-lived keys, but you often want identify binding.
PGP solves basically none of these problems, and offers instead a 1998 API (I'm not kidding, I thought about what year to pin it at) to basic cryptography primitives.
Another thing is also that email itself was not designed with encryption in mind and because it is decentralized and backwards-compatible it is hard to enforce new rules (everyone should use PGP).
But PGP is useful if both sender and receiver agree to use PGP.
> But PGP is useful if both sender and receiver agree to use PGP.
Anecdotally: this works until you add a third person who responds to the thread in plain text, with everything threaded beneath. Or when you do that by accident.
Applied cryptographers will tell you to use Signal or any other E2EE chat.
Signal isn’t owned by the users and independent of third parties the way PGP/GPG is so regardless of who will or won’t suggest a substitute it’s not.
XMPP + omemo
Why is “owned by the users” (whatever that means) the quality you’re testing cryptographic protocols against?
Signal's has buildable source code on the client side and all. However, the server code is closed source and the developers have made disquieting changes like uploading most users' contact lists to the server protected only by Intel SGX that is known to have vulnerabilities exploitable by a nation-scale actor.
The point of E2EE is that you don't need to trust the server that you're talking through. A secure E2EE scheme is secure in the presence of an actively malicious server.
I think SGX is a red herring in this context. You can find it risky or not, but it's (1) not material to Signal's E2EE property, and (2) materially better than email, which sends all contact metadata in plaintext, regardless of whether you try and encrypt your message bodies. Bringing it up in this context seems like a category error.
Is this accounting for the fact that they kill people based on metadata? More technically complex and unreliable protocols such as SimpleX attempt to also protect the metadata.
Is what accounting for that? If you're worried about metadata leaks, you shouldn't be using email, full stop.
By "metadata" GP is presumably talking, as I was, about Signal uploading most users' contact lists to the server with weak protection.
The point is that if the comparison point is PGP-encrypted email, which has no protection for any metadata and passes it on the wire in the clear, raising concerns about Signal’s metadata protections makes no sense.
In the context of this whole big thread, the point is that neither infamously leaky PGP nor Signal keep metadata secure from nation-level actors.
PGP the packet formats, PGP the tool(s), OpenPGP the specs, GnuPG the tool, GnuPG the library; or any of the other libraries? Web of Trust? All of it? None of the above?
Any time this topic comes up, here and elsewhere, I find that most discussions revolve around different understandings and misunderstandings what people mean when they say “PGP”, and rarely lead to anything beyond that. - no this is PGP no you’re wrong that is PGP and so on and on…
All of those things are liabilities (I read them carefully and mentally checked them off one by one; I'm not just being rhetorical). I wrote a sibling comment going into more detail, but happy to answer questions.
Well, gpg2 is an implementation of openpgp and is GnuPG the tool correct? So are you saying that when I `gpg2 --symmetric myfile` I'm doing something harmful rather than useful?
The expectation is that anybody who ends up with the encrypted copy would have an impossible time trying to decrypt it without, I don't know, millions of dollars worth of compute per year for decades to throw at it or something like that.
Each of these bad in a different and exciting way, if your idea of exciting is reading mailing list threads.
(The idea of trust networks is not bad. But PGP’s implementation of them is bad.)
What’s a better one? Are you thinking of something like Keybase?
PGP: The flamethrower (kids love this one)
Almost all of it, yes.
The packet format is awful, full of complexity, backwards compatibility mess, and serious security problems.
The spec is pretty awful in that a lot of the complexity is due to keeping compatibility with things that are a terrible idea. And also in that the general concept of a long lived key turned out to be a bad one.
The library or lack thereof IMO cripped PGP/GPG back when it was relevant. It's nigh impossible to make tooling for it, or it was until Sequoia showed up, which was extremely late. Things like doing stats on keys, or doing anything but what the binary wants to do were terribly painful until Sequoia.
The Web of Trust was an interesting idea for a while, but failed to transition to the modern internet.
By the time you fix all the things what remains looks nothing like PGP, so it amounts to "all of it is bad".
PGP is special to me, I was a beta user when Phil uploaded it to some Colorado BBSes, way back when. He even made time to talk to teenage me about it on the phone.
What's crazy is when it was concieved, we didn't have trusted strong cryptographic primitives. We did have DES but it wasn't trusted. We did have some of these crazy ideas that we all would have "secrets" and you might put those secrets encrypted on a disk in a vault and you'd not even want the feds to get them. Now we have all sorts of much more vetted crypto primitives, but the idea of actual secrets you'd keep in cold storage is largely dead. You're spot on that modern use cases need different APIs and tools and specialized solutions.
Nice username.
https://hackyourmom.com/en/osvita/u-pamyat-pro-kevina-mitnik...
Can you elaborate? I know of commercial softwares that use it still where only the softer has the private key. Seems to work pretty well, but this is slightly out of my normal scope.
The biggest issue of using PGP was using PGP. You were pretty nerdy to be on the internet back then, but even then using PGP was beyond what the majority of people wanted to do. Exchanging keys was problematic. Writing text in one app, encrypting in another app, copying encrypted back to an email was just tiresome.
I'm still glad that it existed as its mere existence seems to have pushed things in the right direction as far as protecting everyone's ability to use encryption if they chose. It just never became the panacea it was envisioned to be.
There were (are? it's been a while) many PGP users on the various darkweb markets. It was great fun teaching people to use it and actually having a community to use it with.
It was pretty awkward to later emerge as the PGP expert at work. I was at that time a bit shy about explaining how I got so comfortable with it.
The fundamental idea of technology such as PGP is that the percentage of stuff worth finding for the authorities needs to be really low. Ie. an incredible amount of "legitimate" innocent traffic needs to be flowing through the technology.
Otherwise, anyone who is using it at all will get court ordered and then, with our current system, you just lose.
Tor solves this by making traffic entirely homogenous such that any "it could be anyone" and by making nodes extraordinarily easy to host (such that any nerd can just leave one running 24/7). Even so there are way too few nodes.
But PGP-over-email is way too metadata leaky, and if you're doing anything that actually has a threat model, you need PGP-over-email to be itself common.
Even today, you still need an external program to your email app to enable encrypted messages with in the email app. With that, the number of encrypted emails will be extremely low relatively. Even looking at Tor, the amount of users is still much lower than the internet in general. To the point, I doubt a very high amount of traffic is "regular" traffic to raise the noise floor.
Huh, Thunderbird ships with a PGP implementation by default? And it's actually very easy to use.
It's easy to explain. "I use PGP for my personal notes (symmetric) and for e-mailing my security conscious friends (public-key)". That's sufficient and not awkward.
Yes but that explanation doesn't help you teach people how to use it in an adversarial context. Then they're just following arbitrary rules set down by privacy nerds for seemingly arbitrary reasons.
One big usability issue these days is that PGP identities come in the form of a file. Lots of people don't have the concept of that anymore.
Dunno that things have gotten much better over the years. End to end encryption is still fairly unusable to most. I think that rather than spending so much time on the cryptography we should instead work on a E2EE usability standard. Having everyone doing their own thing with respect to usability is not working out.
ASCII armored exports suitable for plain text copying and pasting and inclusion in other documents and messages seem to be the norm for sharing. Keys are referred to by keyid or email. To the key database, files seem more like an implementation detail.
It provides the tools necessary to implement a simpler workflow.
The term E2EE has been subverted. Apps like WhatsApp claiming to be E2EE, but only if you actually enable it, so that people think they are being encrypted when they are not does not help. ProtonMail falls into this as well where allowing email to non-encrypted addresses means there is no encryption. It's obvious to some, but not so for the majority. Very few people read the caveats that WhatsApp and ProtonMail provide.
Telegram is the worst though, everyone thinks it's secure and it actually has no security features at all
Can you explain WhatsApp further? Every 1:1 chat I have typically leaves a little note saying it's e2ee
WhatsApp doesn't have any option to enable/disable encryption for standard messages that I can see. Business chat messages are not encrypted and neither are backups (by default) but if Alice messages Bob on a fresh WhatsApp install, the message is E2EE (as far as I know). Is that incorrect?
WhatsApp backups are not encrypted by default.
That’s Telegram. WhatsApp doesn’t have a toggle except for backups.
> ProtonMail falls into this as well where allowing email to non-encrypted addresses means there is no encryption.
You can send password protected mails that the recipient can read in the browser given a pre-shared password. https://proton.me/support/password-protected-emails
> One big usability issue these days is that PGP identities come in the form of a file. Lots of people don't have the concept of that anymore.
Mind. Blown.
To be honest: I keep hearing that PGP was / is difficult to use. That couldn‘t be further from the truth - but somehow it has become an urban myth. From the very first versions that I used on my first Mac up to GPG Mail or Proton Mail I never encountered any significant difficulties and could successfully exchange messages with my peers - both in business and private contexts.
I once had a chat with a security professor who had decided to try to get his group to use encrypted email for all of their communications. And they just couldn't get mailing lists working right with encrypted email.
The sender has to encrypt with everyones individual key wonder why he couldn't get it to work.
In general, a session/thread ephemeral key pair is exchanged with the participants, and only each users private origin signing validates each sender sections. Since the signatures are passively checked, it does not need redone after each append operation.
Thus, participants are pooled under 1 time constrained key exchange, participants sections origins are signed/time-stamped, and the ciphertext expires on a schedule.
Why? so at some future time side-channel key exfiltration can't be used to data mine the entire history of past tapped conversations/ciphertext. Even if a private signing key is stolen, it is difficult to rebuild the lost ephemeral key session.
Have a nice day. =3
My eyes glazed over reading that. I feel like 30 years of internet has proven one thing: the simplest solution always wins. PGP is many things, but simple and obvious are not among them.
Mozilla Thunderbird e-mail client, and Android k9 mail makes pgp/gpg public key handling fairly trivial.
Depends what you do, and if your organization has a persistent clown infestation. Some big business folks still use email as a human to API interface.
Running out-of-band public keychains is not something most people will ever need. =3
Please, enlighten me on how you used PGP where calling it hard to use is so far from the truth. ProtonMail only works if you send messages to another ProtonMail user. It does not protect you when you email someone else.
> ProtonMail only works if you send messages to another ProtonMail user.
Your wording is not entirely accurate.
ProtonMail works perfectly well with external PGP. You can import third-party keys and IIRC it also supports WKD.
So its not "only another ProtonMail user".
IN ADDITION .... you can also send an encrypted, password protected message to a non-Proton Mail email address. The recipient can read it in the browser: https://proton.me/support/password-protected-emails
Your use of ProtonMail+PGP is not how people expect ProtonMail to work when it is claimed to be encrypted email. ProtonMail+PGP is no different than GMail+PGP or AOL+PGP or FastMail+PGP or $coolNameMail+PGP. So what's your point?
Anything+PGP can be encrypted. You still have to use PGP which means creating public/private key pairs, store them correctly, and understand when to use the public key and when to use the private key. You still then need to know how to exchange keys in a trustworthy manner, but that's after you convince someone else to do all of that on their end as well.
So yeah, it's dead simple <facepalm>
What GP likely means is that a Protonmail user can exchange encrypted emails with a non-Protonmail user without doing anything except importing the non-Protonmail user's keys once.
This could allow a single technical user with an elaborate PGP key and email setup to convince his or her social circle (or at least email circle) to switch to Protonmail and follow a set of (comparatively) simple steps to get Proton to recognize the key to their non-Proton address.
Thereby having PGP-encrypted conversations with users who don't know how PGP works, but followed their friends' instructions to use a slightly different webmail interface. Meanwhile the technical user can use a smartcard, a self-hosted email server, or other madness that a normal user would never tolerate.
At least the versions I remember had a really bad UX for marking keys as trusted.
The correct operation for (even locally) marking "this key belongs to person X" is signing the key. Marking it as "trusted" indicates "this key is a CA that can create statements who other keys belong to", but it's easier to find/"understand".
So if you haven't first studied the details of the security model and terminology, you just start increasing the trust level on the key of your communication partner until the warnings go away, not realizing that by doing this, you've made that key a CA and the reason the warnings disappeared is because you now trust the self-signature (in addition to all other signatures the key issued).
It's still extremely difficult.
If we assume that the threshold of what is "difficult" is for example 1) installing a desktop application, or even running a deskop OS.
2) Running an email provider other than what you are already doing (gmail, hotmail, yahoo mail, ...), or switching email providers
3) Copying and pasting text or using files.
This was perhaps a viable thing to do for users in 2005 because if you were on the internet, chances are you at least had a desktop computer, and if you used email chances are you already had to struggle with an email client.
But now? Anything that isn't as easy as installing an app on your device (a device that isn't a full computer) is "difficult".
It's not that it's harder today, it's that everything else is easier (Like telegram/signal and other privacy-minded services), and that there are now 6 billion internet users and most never used a computer and never will.
> It's still extremely difficult.
I don't see how. You just type "gpg -e -r receipient@domain.com filename.txt". It doesn't get much simpler than that. It's not like you are using ffmpeg, imagemagick, or other programs with a hundred switches in it.
Also PGP/GnuPG is not only for email. I encrypt and decrypt hundreds and hundreds of payloads per day, programmatically between trusted and untrusted networks.
And it is mandatory for each employee to upload their public key to our keystore so that we can deliver private information to them securely over Slack, Teams, or other communication channels.
> You just type "gpg -e -r receipient@domain.com filename.txt".
I assure you it is not that simple. For example, I'm a HN user, developer since 30 years. I know that you referred to what's known as a "terminal" or "shell" here, but that's already way WAY too difficult for 99.9% of users.
And even in my terminal I can assure you it won't work: "'gpg' is not recognized as an internal or external command, operable program or batch file."
I could install it. It would be a right pain though. and it doesn't help if the recipient of my email can't install it without me sending a long list of instructions!
Meanwhile my dad had zero problems installing signal. There's a difference to how easy it gets.
Tell me you're a nerd without telling me you're a nerd. Maybe you've moved the goalposts to "it's easy for tech dorks" vs "it's a total pain in the arse for your mom to use'. If the goal is to have encrypted email everywhere, running anything in via command line is out. If you can't recognize that, then you're clearly just trolling
I used it for a little while and Turnpike email software from the UKs Demon Internet integrated it pretty well.
The problem was only one other person I knew actually used it, it didn't really have a justifiable use for most people.
I did use the encrypted mountable drives for a while, that worked very well. I since moved to TrueCrypt and now onto Vercrypt and haven't used a PGP product for probably over 15 years.
Shame really but it just didn't get enough traction.
There's a lot of negativity around pgp, but I actually like the fact that you see the raw ciphertext as opposed to everything happening in the background.
I also like the portability of openpgp.js its pretty versatile in my opinion.
https://openpgpjs.org/
Agree, we use OpenPGP.js in our web projects. It's great for combining it with server-side GnuPG.
It used to be more of a concern without TLS, but now it's reasonably secure to use.
We use it for the user sessions, allowing the client to own their session and identity.
The browser generates the keypair and signs each post and login challenge, so the private key never leaves the client. The server only stores the public key (as a plaintext file in git) and verifies signatures with GnuPG, which means there's no password hash in the database to leak, and the identity is just a fingerprint anyone can audit. Using two independent implementations (OpenPGP.js on the client, GnuPG on the server) is a nice bonus.
I learned C from PGP
so wild, but cool to see