Hacker News Reader

Comment by eduction | Hacker News Reader

If I didn’t want people to encrypt mail to my pgp key I would simply not upload it to a public pgp key directory.

Honestly, what is the complaint here? If you don’t want people to use certain contact info don’t put it on the open internet.

To get your key in that key server not only do you have to submit it you have to verify it via email. It’s literally… to spread it widely… to anyone who wants it… so they can send you encrypted mail. That’s the entire purpose of the thing.

Like if i put my phone number on a billboard I have no right to complain when I get calls.

Take responsibility for your actions.

“ However long we postpone it, we eventually lie down alone in that notoriously un- comfortable bed, the one we make ourselves. Whether or not we sleep in it depends, of course, on whether or not we respect ourselves.” Joan Didion https://www.vogue.com/article/joan-didion-self-respect-essay...

View on HN

I don't know... I thought encrypted emails were cool in like 2002, so I probably have a key on a keyserver. I probably lost the ability to revoke that key, and simply stopped caring after not receiving a single encrypted email in 25 years. So I would be very surprised if someone sent me an encrypted email today.

(I actually do know where my key material is. It's on a smartcard that nothing that exists today can read. Back in the day laptops had smartcard ports! Crazy.)

The one feature of an HP Elitebook that could perhaps be called ”Elite” is that they come with smart card readers built in. USB-readers also exist.

Not all of them. Some models don't support them at all, others only have it as an option. My EB845G8 has the slot, but there's no reader inside.

I also don't have access to that private key anymore anyway, but I'm still using the same email address.

What is indeed missing is a limited validity period of the key, as a certificate would provide. Then everybody would be clear on how long the key can be used.

OpenPGP Keys do have expiration dates/validity periods: https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

The good thing about GDPR is that these keyservers must delete your info after some time unless you periodically renew your consent.

Good thing every company and web server on the planet is in the EU! How else would 10 people make lazy GDPR posts on everything vaguely related?

Even if the web servers are not in EU they must use GDPR if they target EU users.

Good look enforcing GDPR in Panama…

if a tree falls in the woods without any geo-ip blocking, does it have to comply with GDPR?

Where in the GDPR do you find this 'some time'?

AFAIK, and I might be wrong here, you do have the right to be forgotten - art 17. But there is no need to periodically renew consent. As long as the period for consent is understood and is relatable for the reason of the consent, it can be basically for ever. In this case, that period seems to be 'until he withdraws his consent' and that seems fine by my reading of the GDPR.

https://gdpr-info.eu/art-17-gdpr/

https://commission.europa.eu/law/law-topic/data-protection/r...

> Your company/organisation should establish time limits to erase or review the data stored.

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...

> In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review.

Have you not gotten, over the past few years, emails from services you no longer use and probably forgot that you ever setup an account for, informing you that they will delete your account if you don't use it soon? It's because of the GDPR.

"Not longer than necessary" can still mean "permanently" if it's information that remains relevant permanently. And I think that's the case here.

In the same way that any blockchain based system must delete your info after some time...

Hey, smartcards are still a thing ! My company still uses them. I have a 2022 Lenovo laptop whith a smartcard port.

the government still uses them

USB smartcard readers supporting the CCID protocol are cheaply available these days and are natively supported on all major OSes!

I do miss built-in smartcard readers though; carrying a USB reader is just not the same and I usually don't have mine with me when I need it.

That said, I also wish browsers would support the ISO 7816 transport of CTAP2 for WebAuthN using these readers. That would allow me to use a card form factor WebAuthN authenticator not only on my phone (both iOS and Android support CTAP2 over contactless), but also on my computer.

More charitable is that the user thought it would do X and it ended up doing Y. They may have even been happy with X even, if they knew that was going to happen, because the whole thing would have been less confusing.

> I'm at a little bit of a loss here. I totally understand sending me encrypted emails if I've gone through the steps to set the CNAME that indicates that I want to do that, but it doesn't seem like that's how the service works. As far as I can tell, the act of uploading a OpenPGP-compatible key seems to trigger their service to send it as an end-to-end encrypted message.

A similar example is how Windows changed their OS to require a PIN, which can be a password if you figure how to. It then asks you for this when doing completely unrelated to your OS online stuff sometimes, like some of the weird flows to do with using Teams or whatever, and I am not expecting it was asking me for my PC pin because it before that just asked me for my Online username. It is a UX issue.

Neither the sender nor the recipient made an active decision that the respective mail should be encrypted with pgp. That’s the issue here.

They uploaded PGP key to open directory and then verified email, what is this as not an active decision?

It's an active decision to make their key available to people who wish to send them encrypted email. It's not a decision to receive all email in encrypted form.

Im not sure that I see logic here..

> It's not a decision to receive all email in encrypted form.

Except, it is. You can’t control of everyone out only some will send you encrypted email.

I mean, sure, if somebody wants to take a guess on whether I have my private key with me (or even still have access to it at all), that's on them.

But if an email provider purportedly bringing email encryption to the non-GPG-trained masses does, it's a different story.

Using Proton for email means it is. Why use Proton otherwise?

Uploading a key does not imply any decision regarding email. I may need it to sign tarballs or commits for example, and the key could very well have been lost to time.

The presence of a key on a key server is in no way or form an explicit opt-in to encrypted email. That's what the CNAME is for.

Exactly. The only way this makes sense is if Google provided a way to import your PGP key into Gmail, which it doesn’t.

Except you explicitly uploaded an encryption key, not a signing key! This action broadcasts to the world the message "you can encrypt communications to this identifier using this key"!

This is seriously like telling somebody that you can be contacted on a particular phone number and then getting upset that you're getting phone calls. "Who uses the phone these days," you complain, despite having set into motion the sequence of events that led to you getting a phone call! Worse, in this analogy, it's not like you even said "only text this number"; you explicitly applied metadata saying that you would be open to a phone call.

In your analogy, the keyserver is a phone book. You can find keys there, and yes you can try to use them, but it's not like telling someone you can be contacted on a particular phone number, but rather like them digging through a phone book and finding your name in there, possibly for an unused landline that you technically own but isn't wired up - who knows.

Telling you to use a particular phone number - say through a business card, a contact page or a profile - is the analogy matching configuration of your domain to publish your intent, similar to how your domain also specify where you mail server is.

That's a good thing? There's like a billion WhatsApp users encrypting all of their messages without realising it because it just works.

GPG will never be that simple to use. Personally, I hate GPG with such passion, but I'm fully aware it's the best thing we have for asynchronous messaging.

Least you can do is document somewhere that you are doing it, and not silently do it. WhatsApp doesn’t keep it a secret, exactly.

I've never tried Proton myself, but I don't understand how you can consider it to be a "secret". It's literally the only thing I know about them: they've established themselves as a "more secure" email provider, and they back that up by abstracting some of the pain points of using GPG, which is a completely unusable protocol for normal people.

If it was some other email provider that did the same, I'd 100% agree. But with Protonmail, GPG is pretty much the entire reason we're all aware of their existence.

What they do for Proton-to-Proton messages is their business, since they own all the fallout from people losing their keys to that, but to just blindly encrypt to a key somebody might or might not still own the private decryption key for is just reckless.

I just tested it myself, and while there is a visual indicator of that automatic key lookup happening, there's zero way to disable it, nor to even verify which key it picked or to display the key hash.

It seems like a terrible solution halfway between convenience/opportunistic encryption and actual security, combining the downsides of either (a high risk of sending messages the recipient won't be able to decrypt and a moderate risk of encrypting to a key other than the expected one).

Yeah, we'll work to improve the documentation on this.

Though.. note that WhatsApp doesn't have any documentation on their key discovery either, because WhatsApp is not a federated system. Achieving automatic end-to-end encryption in a federated system, when it wasn't there before, isn't so easy. So there's bound to be some growing pains, but we're still trying :)

Are you with Proton? Maybe the documentation you need is just a lock on the sent email that says "Used key for <email> from keys.openpgp.org", and the recipient could also have a cleartext message saying "Encrypted with key for <email> from keys.openpgp.org"?

I haven't read as many blog posts where people get encrypted WhatsApp messages and can't decrypt them.

oddly, it's because whatsapp has a well integrated keyserver so there's never an issue of not knowing which key to use. Weird.

It's not weird. It's the point of the original complain.

Part of the difficulty is that email is a federated system, unlike WhatsApp. Adding end-to-end encryption to a federated system, if it wasn't there before, is a lot more difficult than adding it to an ecosystem that you control in its entirety.

I understand and agree with this. That's why you cannot single-handedly add a feature like Protonmail's, without risking of breaking someone's workflow. I probably have myself some GPG key uploaded on some public server, tied to i-dont-even-remember-which email address of mine, and when I did that I surely didn't expect or imagined that some provider would pull it automatically to encrypt every mail in which I'm the recipient sent by their systems.

I understand Protonmail's approach but I also understand - and share - OP point of view.

That's the thing though, you almost certainly at the time expected people to use it, and then a decade passed and nobody showed up. The problem isn't that you did it, the problem isn't that they used the information, it's that you were an early adopter who forgot the passphrase to your bitcoins. You put that key there because you wanted it used, you don't get to pretend that you've stopped wanting to use it and everyone should totally know that because you haven't used it.

You have a sign out saying encrypted email here, and are mad someone finally read it.

Remove the sign, or change it to foo+secrets@mydomain.com

Op is mad he left the sign out saying come in and play when people came in to play way after his party ended.

Right. And PGP doesn't "just work". So it's foolish to blindly assume someone can receive encrypted mail just because you found a key that seems to match on some public keyserver.

Even if I published a public key, I wouldn't keep the private key on every device, and if I have to dig out my yubikey just to find out you're in town for lunch next Tuesday, we're probably not having lunch.

Yes, this is true.

I never felt comfortable having my private key on my phone, so I can't read encrypted email on the go.

I get one or two encrypted emails on a good year, and they are rarely important (or require encryption really).

> I get one or two encrypted emails on a good year, and they are rarely important (or require encryption really).

Well if only "important" things are encrypted, then the existence of an encrypted message is evidence to whomever you may be trying to hide from that something "important" is going on. Ideally everything would be encrypted, important or not; having all current encrypted things being unimportant is actually better than having only important things encrypted. :-)

My point was that those emails can wait until I'm on my desktop and I can decrypt them.

I should have used "urgency" instead.

I also have a fear of having my private key on my phone, but it's a nebulous kind of paranoid fear. I don't know if there's actually any good reason to have this paranoia or what the best practice is. I suppose having the same key in fewer places inherently increases security, but there has to be a line somewhere... Not accessing email on my phone would be a giant productivity killer.

Because PGP keys are used for more than just encrypting email.

I mostly only use mine to sign release tags for software I publish. Having that key uploaded to a public keyserver is a useful thing to do in that case.

But maybe I wanted to use it for other things... perhaps I just want to sign my email, and not encrypt what I send, and allow others to verify the signature. Having the key out on a public keyserver is essential for that.

Honestly I don't know why acting so rudely about this, to the point of pretentiously quoting a famous author/journalist. Not to mention the fact that you haven't thought through all the various reasons why someone might have a key published. Maybe step back from the keyboard and breathe a bit?

Exactly. My key is on there because we have a shared password-store synched in a private git repo encrypted with the keys of select number of colleagues for some work credentials and keys. It is useful to be able to find each other's keys automatically based on the key fingerprint.

I can probably read e-mail encrypted with it just fine as long as I use Thunderbird with my Fastmail inbox (which is most of the time), but not when using K9 Mail on a smartphone or the web UI of Fastmail.

That's not what public keyservers are for. You're free to use it any other way, but it's unreasonable to shame people who used the keys you advertised in a way that matches general expectations.

Besides, it doesn't make sense to upload keys only meant to be shared among a small number of people to a public keyserver. In your case, the keys better belong in the git repo.

I feel like that defeats the purpose of the validation. If you're storing the keys in the same place as the code, it would be very easy if someone gained malicious access to the repo to change the key and sign it with the new key.

I thought the commenter was using the repo for a password store, not executable code? The only consequence of not validating that would be them entering invalid credentials. Even if they’re dealing with code, watching out for new commits that change keys is enough. That’s something that people should be doing when using keyservers too.

Anyway, the point is public keyservers aren’t a good match for the described use case. If the key is meant to be kept private, it should be shared privately.

Signing keys and encryption keys are separate things in PGP. If you don't want people to use your encryption key, don't encourage everyone to use it by uploading it to a keyserver.

> Honestly I don't know why acting so rudely about this, to the point of pretentiously quoting a famous author/journalist. Not to mention the fact that you haven't thought through all the various reasons why someone might have a key published. Maybe step back from the keyboard and breathe a bit?

Yes please, practice what you preach.

> Signing keys and encryption keys are separate things in PGP. If you don't want people to use your encryption key, don't encourage everyone to use it by uploading it to a keyserver.

I think most people don't know that, and/or don't know how to separate the two. At any rate, it's not particularly convenient. Most people will just generate one set of keys to use, regardless of the intended purpose(s).

Regardless, let's again realize that PGP keys can be used for more than just encrypting email. Maybe I'm using it to encrypt, but not for email.

> Yes please, practice what you preach.

Not sure what you mean. Attempting to equate the tone and words of my comment with that of the toplevel commenter seems a bit in bad faith.

No, my comment was made in good faith.

So, the point about rudeness. PGP keyservers exist for the sole purpose of letting you advertise your keys. Shaming people who used keyservers for what they were designed for is what's rude here. Actually, more than rude. It's a trap.

Next, about actually thinking about all the reasons for uploading keys to a keyserver. Can you actually name a use case that you consider legitimate for discovering encryption keys through a public keyserver? Because your point seems to be that people upload them unwillingly.

You shouldn't be quick to accuse people of rudeness and bad faith in those with different perspectives.

Also,

> I think most people don't know that, and/or don't know how to separate the two.

I'm sure people will understand what "sign only" means when GPG prompts the user to choose what kind of keys to create.

If it prompts them (i.e. if they use --full-gen-key) . --quick-gen-key and --gen-key just assume the user wants both

GPG guides tend to use --full-gen-key, maybe because they're picky about key algorithms and key sizes.

So here's how Arch Linux package signing works:

1. You define a PGP key signature in the package metadata.

2. If you are a part of the Arch Linux project, the key will get installed in user's system as part of the archlinux-keyring package.

3. At package installation time, if your key is not already present, it will look it up on a keyserver. It will then prompt the user if they want to trust this key.

4. If it can't look up the key, it will reject package installation.

I see downthread that Debian works similarly, and also I've seen some people rely on this for publishing signed artifacts on github releases also.

I'm aware how package signing works. What does any of that have to do with my comment?

Step 3 is a reason people publish their keys to keyservers.

Step 3 is reason for people to publish signing keys, not encryption keys. That was the whole point of my original comment.

Let's follow a tutorial for GPG (I'll take the Arch one since I've already discussed, but many are similar): https://wiki.archlinux.org/title/GnuPG#Usage

So here's an interface for key creation in gpg

    $ gpg --full-gen-key
    gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Please select what kind of key you want:
        (1) RSA and RSA
        (2) DSA and Elgamal
        (3) DSA (sign only)
        (4) RSA (sign only)
        (9) ECC (sign and encrypt) *default*
        (10) ECC (sign only)
        (14) Existing key from card

There's also --quick-gen-key which doesn't show this info.

Now put yourself in the boots of a new user: Why would you pick to have a key with less features? Maybe the user thinks they may want to encrypt something in the future. Not to mention, many people did this process years ago, and forgot what they picked.

Then you publish that key with gpg send-keys or the keys.openpgp.org web interface, possibly at a later date, then you just pick the one key ID that you have.

And now you have a key published for signing and encryption, with no intention to use GPG email.

That's irrelevant. The act of publishing has a well-established meaning. Publishing an encryption key, only to shame others who have used your key to send you encrypted data is unreasonable. How is that different from publishing a book and shaming your readers for reading it? "Oh I didn't know that by publishing a book, I was encouraging others to read it!" isn't a good response.

Also, any user of a tool should at least check what the primary purposes of that tool are.

My understanding from the article is that correspondents are not encrypting the mail, but that Protonmail is. So unencrypted messages from Fastmail are being encrypted to a key that Protonmail found on a random keyserver when that email hits the Protonmail server.

This is a common feature provided by privacy oriented email providers. The idea is that the provider will only have access to the unencrypted email at entry to the server but not after that. The email of course can't be signed in any meaningful way, but the original unencrypted message wasn't signed either. This strikes me as the sort of thing that you would want the user to specify a particular key for, but I suppose Protonmail is attempting to increase usability by making it as automatic as possible.

Actually it seems like a feature to me (to be able to exchange encrypted emails so easily between different providers), and a quite nice one actually.

> If I didn’t want people to encrypt mail to my pgp key I would simply not upload it to a public pgp key directory.

I have keys uploaded to PGP directories that I have in the past used for Git commits, and use today for linux package signing.

I've never used encrypted email, so it would be surprising for people to try use it to send email.

Reply on news.ycombinator.com