4 ms·

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 uploadin

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.

kelnos 3y ago
> 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.
- soraminazuki 3y ago
  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.
  - soraminazuki 3y ago
    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.
    - Macha 3y ago
      If it prompts them (i.e. if they use --full-gen-key) . --quick-gen-key and --gen-key just assume the user wants both
      - soraminazuki 3y ago
        GPG guides tend to use --full-gen-key, maybe because they're picky about key algorithms and key sizes.
Macha 3y ago
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.
- soraminazuki 3y ago
  I'm aware how package signing works. What does any of that have to do with my comment?
  - Macha 3y ago
    Step 3 is a reason people publish their keys to keyservers.
    - soraminazuki 3y ago
      Step 3 is reason for people to publish signing keys, not encryption keys. That was the whole point of my original comment.
      - Macha 3y ago
        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 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.

kelnos 3y ago

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

soraminazuki 3y ago
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.
- soraminazuki 3y ago
  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.
  - Macha 3y ago
    If it prompts them (i.e. if they use --full-gen-key) . --quick-gen-key and --gen-key just assume the user wants both
    - soraminazuki 3y ago
      GPG guides tend to use --full-gen-key, maybe because they're picky about key algorithms and key sizes.

Macha 3y ago

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.

soraminazuki 3y ago
I'm aware how package signing works. What does any of that have to do with my comment?
- Macha 3y ago
  Step 3 is a reason people publish their keys to keyservers.
  - soraminazuki 3y ago
    Step 3 is reason for people to publish signing keys, not encryption keys. That was the whole point of my original comment.
    - Macha 3y ago
      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 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.