4 ms·

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.

by fsmv 11mo ago

lrvick 11mo 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 11mo 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 11mo 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.
    - jcgl 11mo ago
      > but still there is a long lived secret a user must maintain somewhere Of course. I'm not suggesting that there's no need to have long-lived private key material. But that does not require some thick GPG-keyring-style concept (especially one that includes both public and private key material). Something like a directory of private keys (like with SSH) fits the bill here and yet bears precious little resemblance to GPG's system. > have a strategy for backup, rotation, discovery, validation, etc etc Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity. > 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. I can agree with this for sure. If you need these various features, then age et al. do not fit the bill. On the other hand, in cases where these systems have adequate functionality or can be shimmed up by other systems, they're lightweight and easy for users to comprehend. Take commit-signing with SSH keys to provide verification mediated by GitHub. Everyone (lol) knows how to generate and manage an SSH key. Easy enough to set up git for signing with that key. Then GitHub uses its own identity layer to show users what commits are verified and which aren't. From the user's perspective, it's super lightweight, easy. When it comes to cryptographic signatures with long-lived identities, it basically doesn't get easier than this. Of course, that GitHub example misses some features, and isn't perfect. But it captures a lot of the value of signing with a bare minimum of error-prone work for the user.
- tptacek 11mo ago
  age has Yubikey support. The idea that the PGP ecosystem "has you covered" on all these points is a bold claim. Certainly people talk about all these things, but when that system is put to the test, it rarely holds up. See for instance the keyserver fiasco.
  - lrvick 11mo ago
    Barely. Age has Yubikey support with no reasonable long term key discovery, backup, or rotation strategy as far as I can tell. All things modern PGP tooling supports. But this is what happens when people try to re-invent the wheel without thinking through all the problems the original solution solved. Also I do put these systems to the test, regularly, and rest billions of dollars of infrastructure on them. Anyone is free to hit up my team in our public channels with any PGP gotchas. Happy to help. It is easy to point at past black eyes of any technology, but I stand by PGP for the use cases we recommend it for today as the least bad option for those use cases. Also, Hagrid keyservers (openpgp.org) do email verification now and are a new generation of keysever built from scratch. The legacy ones are a mess and can be ignored. Today though, Web Key Discovery, PGP DNS records,and Keyoxide are much better ways to discover and distribute keys and signatures now.
    - akerl_ 11mo ago
      Just so I understand, you believe that age’s developer hasn’t thought enough about how to design cryptographic systems or tools?
      - lrvick 11mo ago
        I think even brilliant cryptographers can be wrong, or acting on strong biases formed from a limited perspective. In this case I think they have not thought about personal cryptographic key management and how people use tools like PGP in the wild well enough. An engineer coming from a corporate world where everyone is comfortable with a model of centralized backups, centralized identity, and centralized trust is going to have a very different perspective than say, a Linux distribution maintainer, or those maintaining they core backbone of the internet. I am closer to the latter camp, and obviously have my own biases here, but in spite of them I package Age in stagex, and we support it in keyfork, just so people have choices. Choices are always a good thing. That said, it is my opinion that age does not even begin to approach the threat model or use cases PGP solves for. It does one thing, and it does not even do that thing as well as PGP does in most situations I can think of. Just because someone is experienced in cryptography does not mean they have had significant exposure to environments where decentralized identity and trust are a hard requirement and where no alternatives to PGP exist, and where there is no customer service or IT team to bail you out, which really changes how we tend to think about these problems. In my experience cryptography engineers that work on decentralized open source systems like Tor, blockchains, Linux distributions, etc, tend to strongly favor solutions like PGP as not "good" but the "least bad" option to avoid any single point of trust or failure. Those that have spent their careers in the proprietary FAANG world tend to support using solutions like Fulcio or sigstore and using OIDC to let a central party sign for you with "keyless signing", which to me, is total nonsense. I assume anything that I cannot verify the integrity of for myself to be compromised.
- kiitos 11mo ago
  you're just affirming the consequent here, listing various properties of pgp as requirements in practice, few, if any, of your enumerated "wants" are valuable enough to outweigh their costs to complexity this should be pretty clear from the fact that statistically nobody uses pgp

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.

by fsmv 11mo 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 11mo 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 11mo 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 11mo 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.
  - jcgl 11mo ago
    > but still there is a long lived secret a user must maintain somewhere Of course. I'm not suggesting that there's no need to have long-lived private key material. But that does not require some thick GPG-keyring-style concept (especially one that includes both public and private key material). Something like a directory of private keys (like with SSH) fits the bill here and yet bears precious little resemblance to GPG's system. > have a strategy for backup, rotation, discovery, validation, etc etc Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity. > 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. I can agree with this for sure. If you need these various features, then age et al. do not fit the bill. On the other hand, in cases where these systems have adequate functionality or can be shimmed up by other systems, they're lightweight and easy for users to comprehend. Take commit-signing with SSH keys to provide verification mediated by GitHub. Everyone (lol) knows how to generate and manage an SSH key. Easy enough to set up git for signing with that key. Then GitHub uses its own identity layer to show users what commits are verified and which aren't. From the user's perspective, it's super lightweight, easy. When it comes to cryptographic signatures with long-lived identities, it basically doesn't get easier than this. Of course, that GitHub example misses some features, and isn't perfect. But it captures a lot of the value of signing with a bare minimum of error-prone work for the user.
tptacek 11mo ago
age has Yubikey support. The idea that the PGP ecosystem "has you covered" on all these points is a bold claim. Certainly people talk about all these things, but when that system is put to the test, it rarely holds up. See for instance the keyserver fiasco.
- lrvick 11mo ago
  Barely. Age has Yubikey support with no reasonable long term key discovery, backup, or rotation strategy as far as I can tell. All things modern PGP tooling supports. But this is what happens when people try to re-invent the wheel without thinking through all the problems the original solution solved. Also I do put these systems to the test, regularly, and rest billions of dollars of infrastructure on them. Anyone is free to hit up my team in our public channels with any PGP gotchas. Happy to help. It is easy to point at past black eyes of any technology, but I stand by PGP for the use cases we recommend it for today as the least bad option for those use cases. Also, Hagrid keyservers (openpgp.org) do email verification now and are a new generation of keysever built from scratch. The legacy ones are a mess and can be ignored. Today though, Web Key Discovery, PGP DNS records,and Keyoxide are much better ways to discover and distribute keys and signatures now.
  - akerl_ 11mo ago
    Just so I understand, you believe that age’s developer hasn’t thought enough about how to design cryptographic systems or tools?
    - lrvick 11mo ago
      I think even brilliant cryptographers can be wrong, or acting on strong biases formed from a limited perspective. In this case I think they have not thought about personal cryptographic key management and how people use tools like PGP in the wild well enough. An engineer coming from a corporate world where everyone is comfortable with a model of centralized backups, centralized identity, and centralized trust is going to have a very different perspective than say, a Linux distribution maintainer, or those maintaining they core backbone of the internet. I am closer to the latter camp, and obviously have my own biases here, but in spite of them I package Age in stagex, and we support it in keyfork, just so people have choices. Choices are always a good thing. That said, it is my opinion that age does not even begin to approach the threat model or use cases PGP solves for. It does one thing, and it does not even do that thing as well as PGP does in most situations I can think of. Just because someone is experienced in cryptography does not mean they have had significant exposure to environments where decentralized identity and trust are a hard requirement and where no alternatives to PGP exist, and where there is no customer service or IT team to bail you out, which really changes how we tend to think about these problems. In my experience cryptography engineers that work on decentralized open source systems like Tor, blockchains, Linux distributions, etc, tend to strongly favor solutions like PGP as not "good" but the "least bad" option to avoid any single point of trust or failure. Those that have spent their careers in the proprietary FAANG world tend to support using solutions like Fulcio or sigstore and using OIDC to let a central party sign for you with "keyless signing", which to me, is total nonsense. I assume anything that I cannot verify the integrity of for myself to be compromised.
kiitos 11mo ago
you're just affirming the consequent here, listing various properties of pgp as requirements in practice, few, if any, of your enumerated "wants" are valuable enough to outweigh their costs to complexity this should be pretty clear from the fact that statistically nobody uses pgp