7 ms·

Now can you give us a list of all the features of PGP and a tool that does one specific thing really well?

akerl_ 10mo ago
https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#the-answers https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...
- johnisgood 10mo ago
  Saw it, not impressed, GnuPG has a lot of more features than signing and file encryption. And there are lots of tools for file encryption anyways. I have a bash function using openssh, sometimes I use croc (also uses PAKE), etc. I need an alternative to "gpg --encrypt --armor --recipient <foo>". :)
  - akerl_ 10mo ago
    I guess we'll have to live with you being unimpressed.
  - some_furry 10mo ago
    > I need an alternative to "gpg --encrypt --armor --recipient <foo>" That's literally age. https://github.com/FiloSottile/age https://github.com/FiloSottile/age
    - johnisgood 10mo ago
      No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.
      - some_furry 10mo ago
        Why is a keyring important to you? Would "fetch a short-lived age public key" serve your use case? If so, then an age plugin that build atop the AuxData feature in my Fediverse Public Key Directory spec might be a solution. https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#auxiliary-data https://github.com/fedi-e2ee/public-key-directory-specificat... But either way, you shouldn't have long-lived public keys used for confidentiality. It's a bad design to do that.
        johnisgood 10mo ago
        > you shouldn't have long-lived public keys used for confidentiality. This statement is generic and misleading. Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine AND desired. > Would "fetch a short-lived age public key" serve your use case? Sadly no.
        soatok 10mo ago
        (This is some_furry, I'm currently rate-limited. I thought this warranted a reply, so I switched to this account to break past the limit for a single comment.) > This statement is generic and misleading. It may be generic, but it's not misleading. > Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine. What exactly do you mean by "long-lived"? The "lifetime" of a key being years (for a long-lived backup) is less important than how many encryptions are performed with said key. The thing you don't want is to encrypt 2^50 messages under the same key. Even if it's cryptographically safe to do that, any post-compromise key rotation will be a fucking nightmare. The primary reason to use short-lived public keys is to limit the blast radius. Consider these two companies: Alice Corp. uses the same public key for 30+ years. Bob Ltd. uses a new public key for each quarter over the same time period. Both parties might retain the secret key indefinitely, so that if Bob Ltd. needs to retrieve a backup from 22 years ago, they still can. Now consider what happens if both of them lose their currently-in-use secret key due to a Heartbleed-style attack. Alice has 30 years of disaster recovery to contend with, while Bob only has up to 90 days. Additionally, file encryption, backups, and archives typically use ephemeral symmetric keys at the bottom of the protocol. Even when a password-based key derivation function is used (and passwords are, for whatever reason, reused), the password hashing function usually has a random salt, thereby guaranteeing uniqueness. The idea that "backups" magically mean "long-lived" keys are on the table, without nuance, is extremely misleading. > > Would "fetch a short-lived age public key" serve your use case? > Sadly no. shrug Then, ultimately, there is no way to securely satisfy your use case.
  - baobun 10mo ago
    sq (sequoia) should be able to sort that.
    - johnisgood 10mo ago
      I know, I have been using it recently.
- jhgb 10mo ago
  > Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger. That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.
  - akerl_ 10mo ago
    There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.
    - jhgb 10mo ago
      Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.
      - akerl_ 10mo ago
        I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation. The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick any option that doesn't actually have strong messaging security".
        johnisgood 10mo ago
        > messaging security > WhatsApp Eh? There are alternatives, try Ricochet (Refresh) or Cwtch.
some_furry 10mo ago
https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.
- xeonmc 10mo ago
  offtopic question: as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field? e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positions exists in the overall landscape? where is the cutoff point of "don't roll your own crypto" in the different levels of expertise?
  - johnisgood 10mo ago
    You did not ask me, but you should do your due diligence because there are way too many armchair cryptographers around here.
  - some_furry 10mo ago
    My job title is in the Security Engineer family. I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)
    - xeonmc 10mo ago
      Interesting. In a general sense, where does it fall on the xkcd#435 scale?
    - pseudohadamard 10mo ago
      What you actually want doing crypto is a security engineer, not a cryptographer. To quote Shamir's Law, "cryptography is bypassed, not attacked". No-one ever attacks the crypto, they attack the way it's used, so you need an experienced cryptoplumber to set it up correctly, not a cryptographer who will design a mathematically elegant whatsit and announce "there, solved!". Ideally, this person will also design the system that uses the crypto, because no matter how skilled the people on a standards committee might be their product will always be, at best, a baroque nightmare with near-infinite attack surface, at worst an unusable pile of crap. IPsec vs. Wireguard is a prime example, but there are many others.
miki123211 10mo ago
This is exactly that, in more detail than you could possibly ever ask for: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

akerl_ 10mo ago

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#the-answers https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...

johnisgood 10mo ago
Saw it, not impressed, GnuPG has a lot of more features than signing and file encryption. And there are lots of tools for file encryption anyways. I have a bash function using openssh, sometimes I use croc (also uses PAKE), etc. I need an alternative to "gpg --encrypt --armor --recipient <foo>". :)
- akerl_ 10mo ago
  I guess we'll have to live with you being unimpressed.
- some_furry 10mo ago
  > I need an alternative to "gpg --encrypt --armor --recipient <foo>" That's literally age. https://github.com/FiloSottile/age https://github.com/FiloSottile/age
  - johnisgood 10mo ago
    No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.
    - some_furry 10mo ago
      Why is a keyring important to you? Would "fetch a short-lived age public key" serve your use case? If so, then an age plugin that build atop the AuxData feature in my Fediverse Public Key Directory spec might be a solution. https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#auxiliary-data https://github.com/fedi-e2ee/public-key-directory-specificat... But either way, you shouldn't have long-lived public keys used for confidentiality. It's a bad design to do that.
      - johnisgood 10mo ago
        > you shouldn't have long-lived public keys used for confidentiality. This statement is generic and misleading. Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine AND desired. > Would "fetch a short-lived age public key" serve your use case? Sadly no.
        soatok 10mo ago
        (This is some_furry, I'm currently rate-limited. I thought this warranted a reply, so I switched to this account to break past the limit for a single comment.) > This statement is generic and misleading. It may be generic, but it's not misleading. > Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine. What exactly do you mean by "long-lived"? The "lifetime" of a key being years (for a long-lived backup) is less important than how many encryptions are performed with said key. The thing you don't want is to encrypt 2^50 messages under the same key. Even if it's cryptographically safe to do that, any post-compromise key rotation will be a fucking nightmare. The primary reason to use short-lived public keys is to limit the blast radius. Consider these two companies: Alice Corp. uses the same public key for 30+ years. Bob Ltd. uses a new public key for each quarter over the same time period. Both parties might retain the secret key indefinitely, so that if Bob Ltd. needs to retrieve a backup from 22 years ago, they still can. Now consider what happens if both of them lose their currently-in-use secret key due to a Heartbleed-style attack. Alice has 30 years of disaster recovery to contend with, while Bob only has up to 90 days. Additionally, file encryption, backups, and archives typically use ephemeral symmetric keys at the bottom of the protocol. Even when a password-based key derivation function is used (and passwords are, for whatever reason, reused), the password hashing function usually has a random salt, thereby guaranteeing uniqueness. The idea that "backups" magically mean "long-lived" keys are on the table, without nuance, is extremely misleading. > > Would "fetch a short-lived age public key" serve your use case? > Sadly no. shrug Then, ultimately, there is no way to securely satisfy your use case.
- baobun 10mo ago
  sq (sequoia) should be able to sort that.
  - johnisgood 10mo ago
    I know, I have been using it recently.
jhgb 10mo ago
> Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger. That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.
- akerl_ 10mo ago
  There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.
  - jhgb 10mo ago
    Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.
    - akerl_ 10mo ago
      I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation. The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick any option that doesn't actually have strong messaging security".
      - johnisgood 10mo ago
        > messaging security > WhatsApp Eh? There are alternatives, try Ricochet (Refresh) or Cwtch.

some_furry 10mo ago

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

xeonmc 10mo ago
offtopic question: as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field? e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positions exists in the overall landscape? where is the cutoff point of "don't roll your own crypto" in the different levels of expertise?
- johnisgood 10mo ago
  You did not ask me, but you should do your due diligence because there are way too many armchair cryptographers around here.
- some_furry 10mo ago
  My job title is in the Security Engineer family. I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)
  - xeonmc 10mo ago
    Interesting. In a general sense, where does it fall on the xkcd#435 scale?
  - pseudohadamard 10mo ago
    What you actually want doing crypto is a security engineer, not a cryptographer. To quote Shamir's Law, "cryptography is bypassed, not attacked". No-one ever attacks the crypto, they attack the way it's used, so you need an experienced cryptoplumber to set it up correctly, not a cryptographer who will design a mathematically elegant whatsit and announce "there, solved!". Ideally, this person will also design the system that uses the crypto, because no matter how skilled the people on a standards committee might be their product will always be, at best, a baroque nightmare with near-infinite attack surface, at worst an unusable pile of crap. IPsec vs. Wireguard is a prime example, but there are many others.

miki123211 10mo ago

This is exactly that, in more detail than you could possibly ever ask for: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/