I actually like this behavior ... If you have a key, use it!
I publish a key associated with abofh@ycombinator.com - I would expect things that identify me as such would use it. If it identifies me as a phone number, I wouldn't expect it to use it. If it identifies me by my mastadon handle, I wouldn't expect it to use it. This isn't complicated - the author published "use this public key for me@foo.com" - people did (via automated means), and the author found out he wasn't properly equipped to handle that mail. So he withdrew the publication and everything worked normally.
Nothing in here is anything more than "I did something 10 years ago that bit me in the ass today" - which to be fair, happens to all of us, but don't blame the technology for doing _exactly_ what the user asked for even if they forgot they asked.
this part is incorrect: keys have other uses. It's not because you sign Debian packages that you encrypt your emails. With the same key. Hence the need to have a way to say "this key is for encrypting emails with such method and such protocol".
https://www.gnupg.org/documentation/index.html
Also, why would that be grounds for shaming people who use published keys in a way it was designed for? I don't get your point.
The more general point is that this is why people don't use these systems. There's very little thought given to UX. It's barely usable for average developers, let alone laypeople. Instead there's gatekeeping and stubborn pointing at ideals.
Yes, there are UX problems with PGP. No, that's not relevant to this particular case.
without asking you for it, but not without asking you what to use it for.
Another example. When you put your email address in a contacts page in your blog, is the message "don't email me, ever" unless you add another "yes, you can use this for email purposes" disclaimer? If that's the case, shouldn't that disclaimer need another "yes, this disclaimer is what you think it means" disclaimer? And shouldn't that disclaimer also ... you get the idea.
Some actions, such as publishing something, has well-established meanings. You can't yell at people for thinking "publish" meant publish.
I don't believe this to be the case. It's fine that we don't agree on this. Do you have sources? Because that would settle the discussion for good. Happy to be wrong. I'm not an expert on this stuff anyway.
Now, I also believe that it's not a big deal, if you unexpectedly receive an encrypted mail you can still decrypt it using your private key and if you don't know how to do this, you can always send your recipient "Hey, sorry, you sent me an encrypted mail that I can't decrypt, can you send me one without encryption?".
Unless, of course, your recipient's provider doesn't let them do this.
Maybe Proton doing this will push the ecosystem toward a more seamless support for encrypted mail, so it might even be a good thing. I don't know.
Here's a snippet from the PGP FAQ last updated in 1998:
> Public Key Servers exist for the purpose of making your public key available in a common database where everybody can have access to it for the purpose of encrypting messages to you. Anyone who wants to write you a message, or to check a signature on a message from you, can get your key from the keyserver, so he doesn't have to bother you with it.
https://www.pgp.net/pgp-faq/faq.html#8.1
Of course, the writing was on the wall for PGP in email when I created my first keys a decade ago. But it was still touted as a tool for encrypting emails even then during the height of the Snowden disclosures. The complete loss of interest in using it for email is a relatively new phenomenon.
If you have a bunch for different use cases (or like, levels of security/secrecy/revoking-this-will-be-a-nightmare), which you've set your one email address as recipient for, which of those is "default"?
The keyserver and protonmail also are entirely separate. I wouldn't expect the two entities to be communicating with each other if I hadn't opted in. It feels weird, like when private companies harvest your data without asking.
The only non-theoretical use of a PGP encryption key is email.
> (different) levels of security/secrecy/revoking-this-will-be-a-nightmare
Using multiple keys don't offer added security or secrecy.
Also, keys.openpgp.org lets you delete keys as long as you have access to your email.
> It feels weird, like when private companies harvest your data without asking
This is nothing like data harvesting, which may be why you prefixed your statement with "it feels like." Nobody is obtaining private or even semi-private data that can be used against you.
Also,
> private companies
keys.openpgp.org is a open source community project. It's not an evil for-profit data-hoarding entity that's implied by those two words.
I'm curious, what do you think a PGP keyserver is for? You make it sound as if there are no legitimate use for downloading encryption keys from it. Which leads to another question, why upload the keys at all?
Why wouldn't it?
I've got a chinesium grade tablet with some very convenient features, but between self-reenabling background services, the completely bypassed permission system, the device crashing whenever adb is used, it still trying to access wifi networks after deleting them and "resetting" the system, ..., I'm pretty sceptical about the privacy of the data, you can encrypt after it gets synced to their cloud.
I dont have any email accs I care about added to this device, but I can imagine some people wanting to read some emails on other lesser trusted devices.
A simple solution would be giving lesser trusted devices only access to lower security keys.
That puts the burden of the decision of picking the right security level on the sender though, right? I don't see that ever becoming a thing.
I use this on some repos https://github.com/AGWA/git-crypt
And occasionally to encrypt files, or receive encrypted files.
These are practical things which are non-theoretical.
> Using multiple keys don't offer added security or secrecy.
Depends on how careful you are or want to be, with your private key. My house key isn't the same as my car key isn't the same as my bike key.
> This is nothing like data harvesting
Alright fair, bad example. What I was grumbling about was more the lack of any clear communication that you've been auto-opted-in to a feature on protonmail, with no user interface signal indicating so, leading to confusion for a couple months like in TFA. I definitely wasn't casting shade on the opengpg keyserver, nor protonmail. It's the "hey! I didn't check a box for this, and it's not mentioned anywhere in the protonmail docs" hidden functionality which could do with some clarification.
I'm a forgetful creature. If I intentionally put my key on a keyserver, because I'm playing around and learning about PGP, will I make the connection between it and protonmail a few months down the line if I move my email account to them? Unlikely.
It's a nice automated feature. Protonmail-to-protonmail e2e encryption makes a lot of sense. I just think protonmail-to-non-protonmail e2e needs a tooltip in the UI, and the option to opt out, potentially with the ability to opt out for specific email addresses. I wouldn't at all assume it would be on by default even IF I've been actively using PGP in my email clients, because it's something you usually have to manually set up yourself, very explicitly. That, and 99.9% of emails are plaintext.
Anyhoo, one thing I forgot which kind of negates the "what if I have multiple encryption keys tied to my email" is the fact that the opengpg keyserver does tie 1 email address to 1 key so you can't publish multiple encryption keys, fair enough. Git-crypt and file encryption, I set my associated email address to use +tags eg me+git@email.com, so as far as protonmail etc are concerned there's only one key per logical email address.
What an uninformed blanket statement. I use GPG many times per day, at work and otherwise, none of them for email:
Commit signing, SSH key storage (in a GnuPG smart card), deb package verification are only the ones that come to mind.
You use your encryption key for that? Which PGP implementation does that? I use my signing key.
> SSH key storage
Again, I use my authentication key for that.
> deb package verification
I use the published signing keys. Never had to use any other key type.
> What an uninformed blanket statement.
I'm sorry for my ignorance. Could you at least provide an example that's valid?
- I used to use `pass`, a password manager based on GPG. That needed the encryption key.
- Sharing of confidential data with coworkers at more than one job.
- Future-proofing: Even though I might not be using an encryption key now, creating all three (encryption, signing, authentication) is a common flow when using GnuPG cards, and then I do want to sync all three to the key server for convenience (so that I can use them at a different machine, for example) without broadcasting to the world "hey, email me encrypted stuff to keyid 0xABCD1234!".
Maybe I'm using them wrong in your view, but I don't see why your view is somehow the canonical one, given all the non-email examples I and other people in this thread have provided.
I use a backup application that encrypts my backups using PGP.
Granted, that certainly doesn't require a published public key. But your assertion is incorrect.
You can back up public keys and restore them just like any other file. I don't see why a public key file should require special treatment from any other file requiring backup.
Who defined that?
> It's not a private file syncing service.
No, it's a public file syncing service :)
> Whatever it is, you don't want your private electronic mail (email) or confidential documents read by anyone else.
https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html
It was designed for private electronic mail.
Or the PGP FAQ linked by the MIT keyserver:
> PGP is a program that gives your electronic mail something that it otherwise doesn't have: Privacy.
Where did you get your definition from? Because it's the first time I ever heard of it.
> Although OpenPGP’s main purpose is end-to-end encrypted email communication, it is also utilized for encrypted messaging and other use cases such as password managers.
Tools and protocols evolve. Just because it was generated with email in mind doesn't mean that that's what people use it for these days.
GnuPG card doesn’t store anything other than the private key, so there’s a risk of losing access.
I’m not sure if that protocol Protonmail is using would pick up such keys without email verification, though.
I do mind software or services taking that as an implicit statement of "go ahead, encrypt email to me using this" when it can clearly cause confusion and irrecoverable messages in many cases.
That said, we don't actually know if Protonmail really does search all keyservers (including the "old-style" ones, i.e. the ones where anybody could publish anything in an unverified manner and the "web of trust" is used to figure out which key is in fact trusted), or only the new ones that perform email verification.
If it's the latter, I think performing email verification could be considered a bit more of an opt-in statement to receiving encrypted mail.
They wrote in the book "me@foo.com: use key" - and then people did. If he wanted different behaviour, he could have published "someoneelse@foo.com" and then they wouldn't use it to email _him_.
Well, yes, actually, that is what I would expect. (Well, not necessarily in person, but via a different communication channel, even by unencrypted email.)
I remember when I was first playing around with PGP more than 20 years ago. The usual convention was to talk to the other party first about encrypting your messages, and not to assume that the recipient could receive and decrypt them in all circumstances.
Just blindly downloading keys from a keyserver and hoping they're the real thing was not the idea.
I do have an OpenPGP key published to the key servers, mostly for toying around with GnuPG cards, but as soon as anyone starts emailing me encrypted messages without any context, I’ll delete it.
It's not a security risk to read an encrypted message. Why would you delete an encrypted message?