Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Absolutely not without a flag on the key that indicates “encrypt email to this key by default”, or at least the domain admin having explicitly pointed WKD to the public key servers.


This is such a bizarre take to me. If you don't want people using your key to encrypt email to you, why are you uploading your key to a service designed to help people find it to encrypt email to you?


> to encrypt email to you

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".


Then only upload a signing key. Don't upload encryption keys. PGP is capable of making that distinction.


Where do the docs on that page indicate that? Don't assume all users who are interested in privacy are experts on how keys work.

https://keys.openpgp.org/upload


Why should a service for publishing keys host manuals for GPG? The manuals are available at www.gnupg.org, where they belong.

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 specific point is that there's nothing on the directory site to indicate that uploading a key to the directory will cause people to start encrypting your emails. From the description it sounds like a directory of pgp keys, nothing more and nothing less.

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.


What do you think a public directory of PGP keys exist for? To publish them so that other people can use them without asking you for one in person. Why would it need a oh-this-is-not-actually-meant-to-be-public-it's-a-trap-for-shaming-people-who-reasonably-assumed-otherwise flag? Would that flag also need another this-flag-should-not-be-respected flag?

Yes, there are UX problems with PGP. No, that's not relevant to this particular case.


> To publish them so that can use them without asking you for one in person

without asking you for it, but not without asking you what to use it for.


Just like how people purchasing books from a bookstore have to ask each author what they're going to use the books for? I think not. The act of publishing a book clearly indicates that the author wants the book to be read. It's the same thing with public keyservers and PGP encryption keys.

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.


Your comparisons don't help, they are just verbose ways for you to (re-)state that you think publishing a key on keys.openpgp.org obviously means "you can email me encrypted" and that others may be a bit stupid to think otherwise (a bit like your "You can't yell at people for thinking "publish" meant publish" sentence, honestly, cut the bullshit)

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.


I mean encrypting email was what PGP was created for. It's my understanding that uploading keys was a sign that you wanted your emails to be encrypted as much as possible. Not a mere "I'll accept encrypted emails, even if begrudgingly."

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.


Yes, but how many other things can you think of other than email which you would share your encryption public keys for? Honestly email would be at the bottom of applications I would think of, even when registering keys with a key server.

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.


> Yes, but how many other things can you think of other than email which you would share your encryption public keys for?

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?


> Using multiple keys don't offer added security or secrecy.

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's terrible operational security. You shouldn't be using the same email account in that scenario. Entering email credentials into an untrusted device will allow that device to send and receive emails, meaning it can read unencrypted emails. That's a major risk, considering that people might forget to encrypt them. Or they might simply follow other people's advice here and not use your advertised keys. Even granting untrusted devices access to encrypted emails pose a non-zero risk too because there are many ways it can go wrong.


> 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.


> The only non-theoretical use of a PGP encryption key [that would use keys published on a keyserver] is email.

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.


> The only non-theoretical use of a PGP encryption key is email.

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.


> Commit signing

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?


Sorry, missed the "PGP encryption key". But still:

- 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!".


None of those use cases should involve a public keyserver if you don't want people to email you encrypted stuff. Keyservers are literally there to "broadcast to the world 'hey, email me encrypted stuff to keyid 0xABCD1234!'."


Well, I use keyservers, and I don't intend to broadcast that fact.

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.


Because the act of publishing has a well-established meaning. The same reason I can't publish a book and shout at people who read it. "I wrote it for my eyes only, how dare you read it!" is a ridiculous thing to say.


> The only non-theoretical use of a PGP encryption key is email.

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.


Right, I should've phrased it as PGP encryption keys obtained from a public keyserver.


Backing up keys stored on a GnuPG card (e.g. on a Yubikey) does require that.


It doesn't require that. You have the option of doing so.

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.


And I don't see why publishing a public key file to a key server should trigger any special semantics regarding email encryption without an explicit "I currently have this key accessible, go ahead and encrypt email to me using it" flag.


Because that's what a public keyserver is for. It's not a private file syncing service. You can use it as one, but don't get mad at others when they use public keyservers as intended.


> Because that's what a public keyserver is for.

Who defined that?

> It's not a private file syncing service.

No, it's a public file syncing service :)


Well, ask the creator of PGP:

> 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.

https://pgp.mit.edu/info.html

Where did you get your definition from? Because it's the first time I ever heard of it.


From www.openpgp.org:

> 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.


Yes, but that still doesn't grant you permission to yell at people using it as originally intended. And whatever the "modern" usage for PGP may be, the purpose of keyservers still remain the same: publishing keys for others to use, or discovering them.


Backing up my signed public keys, for example.

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.


If you don't mean to publish your keys, you'd be better off backing them along with your other files rather than uploading it to a public keyserver.


I don't mind publishing my keys at all, and in fact for some of my applications it makes GPG much more ergonomic to use.

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.


To play around with it?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: