Live data from Hacker News

Switching from GPG to Age

luke.hsiao.dev

81–90 of 148 posts

Re: Switching from GPG to Age

#81
post #75

Earlier quoted context omitted.

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.

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…

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.

Re: Switching from GPG to Age

#82
post #81

Earlier quoted context omitted.

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…

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.

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.

Re: Switching from GPG to Age

#83
post #60
post #49

Earlier quoted context omitted.

I have only read that single post by that author and it passed my logic smoke test on a first pass. I am not commenting on any other work by that author and this seems like an ad hominem argument rather than refuting any content of that article. Also I never actually disagreed that PGP as a specification, has a lot of 1990s holdovers given its history and age. Thankfully we have modern tooling now with reasonably sec…

This has been a mostly unproductive thread that has done a good job of avoiding the point of my original comment, which is that the archaisms in PGP are not merely a consequence of the GnuPG implementation, but also deeply embedded into the standard itself. I don't care if you feel like PGP is still a worthy tool (I don't think it is, but I get that we can go back and forth on that). You made (by implication) a false…

I have made no false claims or implications that I am aware of.

Mainly I was arguing at your implication that PGP is the wrong tool for any job as your link concluded.

I don't doubt you or a lot of people could build something better, but nobody has yet, and I doubt any will get it as widely adopted and supported end to end for all the use cases PGP is used for today. PGP is here to stay, and thus must be maintained and improved.

I don't see bike shedding about things that could have been done better historically in the spec itself as productive as there are no significant security problems with any of the active uses of PGP I use or am aware of in wide use today, if done with modern tools and with modern cipher defaults.

I would not recommend generating keys with GnuPG today any more than I would recommend using Internet Explorer. Advising against old broken implementations is not the same thing as saying we should abandon an established widely used cryptographic identity standard for which no comparable alternatives exist. Especially when alternative tooling with reasonable secure defaults exists now.

I doubt this discussion was productive for you or me, but hopefully it will be productive for others reading trying to make sense of their choices and tradeoffs.

I do appreciate people like you keeping me honest on this stuff regardless.

Re: Switching from GPG to Age

#84
post #48
post #39

Earlier quoted context omitted.

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 hi…

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

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

Re: Switching from GPG to Age

#85
post #81

Earlier quoted context omitted.

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.

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 d…

No thanks, I think we’ve gotten all we’re going to get out of this thread.

Re: Switching from GPG to Age

#86
post #66
post #45

Earlier quoted context omitted.

As for how it improves security, I'm going to hazard a guess that many of the people sending zikduruqe those messages hadn't previously set up a PGP key. So by asking for the public key and refusing to send them the credentials until he receives it, he's forcing them to set one up, which then makes it possible for them to do things like sign messages. Just making someone set up a keypair doesn't mean they'll use it c…

It’s so easy to use insecurely that I will argue that employees setting up PGP keys and then potentially trying to use them does weaken the company’s security posture.

Care to elaborate on this? How come using PGP insecurely is somehow more insecure than not using it at all? And what do you exactly mean by using it insecurely? Care to give me an example of this insecure use of PGP?

Re: Switching from GPG to Age

#87
post #85

Earlier quoted context omitted.

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 d…

No thanks, I think we’ve gotten all we’re going to get out of this thread.

I agree.

Re: Switching from GPG to Age

#88
post #71
post #70

Earlier quoted context omitted.

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…

Just so I understand, you believe that age’s developer hasn’t thought enough about how to design cryptographic systems or tools?

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.

Re: Switching from GPG to Age

#89

Earlier quoted context omitted.

What do you mean? I use GPG with SSH (or SSH with GPG) all the time, and I need gpg-agent for that. GPG's agent replaces ssh-agent and serves SSH keys derived from your GPG key. Can you do this with Age? If not, then I am going to stick to GPG.

I'm unsure what was unclear. It simply does not provide PIV support and it interferes with other software that wants to utilise SmartCards. Can Age interfere with all SmartCard usage? No clue.

Oh well, let us just agree on that comparing Age to GPG is silly, ergo "Switching from GPG to Age" is silly, unless it is "Switching from GPG to Age for file encryption".

Age doesn't do signing, key infrastructure, or email. Minisign/signify only sign. None are GPG replacements. They're partial feature subsets that are simpler because they do less.

So, to summarize these tools:

- Age: Only does file encryption, no signing, no key management infrastructure, no email integration

- Minisign/Signify: Only signing, no encryption

- GPG: Encryption, signing, key management, email integration, multiple recipients, subkeys, revocation certificates, web of trust (even if unused), smart card support, etc.

You cannot just simply switch from GPG to Age unless you are only doing file encryption. If this is the case, then sure, you can.

Re: Switching from GPG to Age

#90
post #88
post #71

Earlier quoted context omitted.

Just so I understand, you believe that age’s developer hasn’t thought enough about how to design cryptographic systems or tools?

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 goin…

I think Filippo Valsorda has in fact thought pretty hard about the issues you're talking about, and that, by contrast, the track record of the PGP community on those same issues is pretty dismal.
Post reply on HN