8 ms·

Age only covers encryption. It does not cover signing, ssh, web of trust, hierarchical keys, key discovery, etc. It is in no way a replacement for a modern PGP

by lrvick 1y ago

Age only covers encryption. It does not cover signing, ssh, web of trust, hierarchical keys, key discovery, etc. It is in no way a replacement for a modern PGP keychain. Ignore GnuPG which is a shit show stuck in the 90s. PGP != GPG For a modern long lived personal PGP keychain use Keyfork on AirgapOS which gives you a secure 24 word mnemonic backup, optional split backup across redundant smartcards, and a separation of a CA key and daily driver subkeys on smartcards all done correctly so you do not have to think about it. I would suggest a Nitrokey Pro due to open source rust firmware, though Yubikeys are supported. From there you can use your smartcard for ssh, password management, git commit signing, etc. and make your key easy to discover without impersonation using keyoxide to have all your services, domains, etc attest to your key, as well as any humans who vouch for you. A proper PGP keychain is a long lived digital passport first, that has encryption and authentication subkeys. https://git.distrust.co/public/keyfork https://git.distrust.co/public/keyfork https://git.distrust.co/public/airgap https://git.distrust.co/public/airgap

justincormack 1y ago
ssh covers ssh and now signing, eg for git commits. The vouching and web of trust stuff never worked for mist people.
- lrvick 1y ago
  Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
  - epistasis 1y ago
    Why do you call it abuse?
    - lrvick 1y ago
      OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation. Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is. I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right. Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
      - justincormack 1y ago
        All the docs encourage you to use a different ssh key for signing I think; certainly I do.
        lrvick 1y ago
        There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter. SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method. Now you solved the overloaded key problem, while making key discovery worse. Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
        epistasis 1y ago
        I'm only familiar with GitHub, but signing keys are kept entirely separate from authentication keys, and must be uploaded separately. A GitHub user's signing keys are available at a different API endpoint: https://api.github.com/users/username/ssh_signing_keys https://api.github.com/users/username/ssh_signing_keys https://docs.github.com/en/rest/users/ssh-signing-keys?apiVersion=2022-11-28#list-ssh-signing-keys-for-a-user https://docs.github.com/en/rest/users/ssh-signing-keys?apiVe... as opposed to the auth public keys, which are at: https://github.com/username.keys https://github.com/username.keys
- aborsy 1y ago
  It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps. Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too! The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.
Arubis 1y ago
I like the idea of AirgapOS; "just turn off the network" has always felt a little dissatisfying. That said, if you're already in the GnuPG ecosystem, https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html https://incenp.org/notes/2015/using-an-offline-gnupg-master-... will cover you for pretty much everything here except the mnemonic backup using baseline tooling. I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.
- lrvick 1y ago
  > I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like. Not possible as GnuPG does not expose access to the cryptographic seed. That said a mnemonic you generate and backup with keyfork is entirely compatible with GnuPG should you still want to use it as a client for keyfork-provisoned smartcards. You can also use that same mnemonic to generate any other cryptographic keys you want for any purpose, including Age.
tptacek 1y ago
No, PGP is also a shit show stuck in the 1990s. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
- lrvick 1y ago
  Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed. Nothing else comes close to the broad compatibility PGP offers. Just need to ignore legacy ciphers. I suggest looking at the links. Latacoras take on this is IMO wildly out of date (6 years old to be fair). PGP powers the core software supply chain security trust layer for the Linux distributions and tooling that power the whole internet and the standard does get updated. PGP is not going away, but it is being upgraded.
  - tptacek 1y ago
    The post covers this (not Keyfork itself, but Sequoia, on which Keyfork appears to depend).
    - lrvick 1y ago
      Sequoia is only used as a library for a few crypto primitives that there are multiple alternatives for now we will be switching to. Thankully, because of standards, we can switch to a leaner library set without breaking compatibility. https://codeberg.org/heiko/pkcs11-openpgp-notes https://codeberg.org/heiko/pkcs11-openpgp-notes
      - tptacek 1y ago
        I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own. Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.
fsmv 1y ago
That's the whole point of age. That pgp is too complex and overloaded with features. By focusing on encryption only he can really get it right.
- lrvick 1y ago
  Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so. If that is the case, you probably want: 1. a long lived keychain 2. a way to securely load private keys into smartcards such that they cannot be stolen by malware 3. a strategy to recover lost keys 4. a strategy to migrate from one keychain to another one 5. a way to notify people/software to stop encrypting data to your old key 6. a way to switch between multiple competing software implementations with a long established spec The PGP ecosystem has you covered on all points. Age does few of these, and none of them well. Doing things the right way takes a bit more up front thought and time, and you will thank yourself later. That said, for the sake of compatibility, keyfork keys can be used with any pgp toolchain, as well as with signify, age, or whatever.
  - jcgl 1y ago
    It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext. What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that higher layer to “compile down to” or emit some kind of key allowlist or denylist that can be consumed by the cryptosystem layer beneath it. The work-in-progress VOA[0] spec is an example of such an upper layer. [0] https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/ https://uapi-group.org/specifications/specs/file_hierarchy_f...
    - lrvick 1y ago
      > It’s unclear to me any stateful keychains are implied here. Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc. > it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too. What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.

by lrvick 1y ago

justincormack 1y ago

ssh covers ssh and now signing, eg for git commits. The vouching and web of trust stuff never worked for mist people.

lrvick 1y ago
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
- epistasis 1y ago
  Why do you call it abuse?
  - lrvick 1y ago
    OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation. Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is. I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right. Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
    - justincormack 1y ago
      All the docs encourage you to use a different ssh key for signing I think; certainly I do.
      - lrvick 1y ago
        There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter. SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method. Now you solved the overloaded key problem, while making key discovery worse. Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
        epistasis 1y ago
        I'm only familiar with GitHub, but signing keys are kept entirely separate from authentication keys, and must be uploaded separately. A GitHub user's signing keys are available at a different API endpoint: https://api.github.com/users/username/ssh_signing_keys https://api.github.com/users/username/ssh_signing_keys https://docs.github.com/en/rest/users/ssh-signing-keys?apiVersion=2022-11-28#list-ssh-signing-keys-for-a-user https://docs.github.com/en/rest/users/ssh-signing-keys?apiVe... as opposed to the auth public keys, which are at: https://github.com/username.keys https://github.com/username.keys
aborsy 1y ago
It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps. Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too! The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.

Arubis 1y ago

I like the idea of AirgapOS; "just turn off the network" has always felt a little dissatisfying. That said, if you're already in the GnuPG ecosystem, https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html https://incenp.org/notes/2015/using-an-offline-gnupg-master-... will cover you for pretty much everything here except the mnemonic backup using baseline tooling. I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like.

lrvick 1y ago
> I presume you can get a shell utility to pipe your key in and get that mnemonic version out if you'd like. Not possible as GnuPG does not expose access to the cryptographic seed. That said a mnemonic you generate and backup with keyfork is entirely compatible with GnuPG should you still want to use it as a client for keyfork-provisoned smartcards. You can also use that same mnemonic to generate any other cryptographic keys you want for any purpose, including Age.

tptacek 1y ago

No, PGP is also a shit show stuck in the 1990s. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

lrvick 1y ago
Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed. Nothing else comes close to the broad compatibility PGP offers. Just need to ignore legacy ciphers. I suggest looking at the links. Latacoras take on this is IMO wildly out of date (6 years old to be fair). PGP powers the core software supply chain security trust layer for the Linux distributions and tooling that power the whole internet and the standard does get updated. PGP is not going away, but it is being upgraded.
- tptacek 1y ago
  The post covers this (not Keyfork itself, but Sequoia, on which Keyfork appears to depend).
  - lrvick 1y ago
    Sequoia is only used as a library for a few crypto primitives that there are multiple alternatives for now we will be switching to. Thankully, because of standards, we can switch to a leaner library set without breaking compatibility. https://codeberg.org/heiko/pkcs11-openpgp-notes https://codeberg.org/heiko/pkcs11-openpgp-notes
    - tptacek 1y ago
      I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own. Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.

fsmv 1y ago

That's the whole point of age. That pgp is too complex and overloaded with features. By focusing on encryption only he can really get it right.

lrvick 1y ago
Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so. If that is the case, you probably want: 1. a long lived keychain 2. a way to securely load private keys into smartcards such that they cannot be stolen by malware 3. a strategy to recover lost keys 4. a strategy to migrate from one keychain to another one 5. a way to notify people/software to stop encrypting data to your old key 6. a way to switch between multiple competing software implementations with a long established spec The PGP ecosystem has you covered on all points. Age does few of these, and none of them well. Doing things the right way takes a bit more up front thought and time, and you will thank yourself later. That said, for the sake of compatibility, keyfork keys can be used with any pgp toolchain, as well as with signify, age, or whatever.
- jcgl 1y ago
  It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext. What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that higher layer to “compile down to” or emit some kind of key allowlist or denylist that can be consumed by the cryptosystem layer beneath it. The work-in-progress VOA[0] spec is an example of such an upper layer. [0] https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/ https://uapi-group.org/specifications/specs/file_hierarchy_f...
  - lrvick 1y ago
    > It’s unclear to me any stateful keychains are implied here. Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc. > it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too. What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.