4 ms·

So I email you asking for something. You say “send me your public key first”. I generate a key pair and send the public key to you. You encrypt response givin

• johnisgood 11mo ago
  The question makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme. This problem exists regardless of PGP. If someone's Slack is compromised: With PGP: attacker gets credentials encrypted to their key Without PGP: attacker gets plaintext credentials But both fail at the same point: verifying who you're talking to. That's not a PGP problem, it's a "doing password resets over unauthenticated Slack" problem. PGP does provide multiple identity verification mechanisms, e.g. web of trust, key signing, fingerprint verification, in-person key exchange, and Keybase-style social proofs linking keys to verified accounts. The workflow described just doesn't use them. Identity verification is required for ANY secure credential exchange system; you either verify keys properly (signed by trusted parties, verified fingerprints, pre-enrolled, social proofs) or you have the same problem with passwords, TOFU SSH keys, or anything else. Are you criticizing PGP for not solving a problem that the workflow simply didn't implement a solution for?
  • akerl_ 11mo ago
    I’m saying asking somebody for a public key in the example scenario is pure security theater, no matter if it’s PGP or some other scheme.
    • johnisgood 11mo ago
      That's only true if the key's authenticity isn't verified. If you just accept any key a person gives you, then yes, it's meaningless. But if you independently confirm the key's fingerprint through a trusted channel, it becomes a real security measure that prevents impersonation and ensures confidentiality. The workflow as described (no verification step) is theater. But that's true for any credential exchange without identity verification, PGP or otherwise. The issue isn't PGP, it's skipping the verification step. PGP provides the tools (fingerprint verification, web of trust, key signing), but you have to actually use them.
      • akerl_ 11mo ago
        I didn’t say the issue with this example scenario is PGP. The scenario is theater (if you have an out of band lookup for verification, just use that. Don’t bother asking for pub keys). Also in parallel PGP is trash.
        • johnisgood 11mo ago
          The out-of-band verification is for initial key enrollment, not every credential exchange. You verify the fingerprint once through a trusted channel, then use that verified key indefinitely without needing the trusted channel again. That's the entire value proposition: establish trust once, communicate securely many times. Without this, you'd need out-of-band verification for every single credential exchange, which doesn't scale. As for "PGP is trash"... That's a different argument entirely, and you've provided zero technical justification for it. If you have specific criticisms of PGP's cryptographic primitives, key management model, or implementation security, make them.
          • akerl_ 11mo ago
            No thanks, I think we’ve gotten all we’re going to get out of this thread.
            • johnisgood 11mo ago
              I agree.
• rmunn 11mo ago
  Well, I've been assuming that zikduruqe is competent and knows how to pick up a phone and call the person (looking up a phone number in the company database) to verify that the public key came from him via fingerprint-checking over the phone. Sometimes people leave steps out so as not to write essays in a comment box.
  • akerl_ 11mo ago
    My confusion here is that if you're doing that, why bother with the cryptography? You can just look the person up in the company database, call them, and say "Hey! Did you just request a password reset?". If one of your pre-requisites is "There is a trusted out-of-band way for me to validate comms with this person", the crypto is just extra bits.