Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching from GPG to Age

luke.hsiao.dev

Post reply on HN
Print view View original

71–80 of 148 posts

Re: Switching from GPG to Age

#71

Post by akerl_ »

lrvick wrote: post #70
tptacek wrote: post #62

Earlier quoted context omitted.

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.

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?

Re: Switching from GPG to Age

#72

Post by lrvick »

tux1968 wrote: post #58
lrvick wrote: post #51

Earlier quoted context omitted.

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

Isn't this more of a theoretical problem, rather than a practical one? In what situations do you want people to discover your key? You create a key pair for Github, upload the public key, and you're done; you can securely communicate with Github. Nobody ever has to discover it. Do they?

> In what situations do you want people to discover your key

Just to name some of the most common use cases I have:

1. When people in my orgs want to encrypt sensitive information to me, e.g in encrypted password databases over git.

2. When prospective new clients or security researchers want to encrypt sensitive requests to me via email. Have some in my inbox right now from today.

3. When people want to verify that commits or code reviews I signed on security critical software were really signed by me, and not masquerade malicious code as mine in a rebase, etc.

4. When people want to verify that public reproducible builds of artifacts I maintained are built by multiple maintainers.

These use cases all rely on a well published set of public keys shared with the public in ways with sufficient history and signatures so no one can impersonate me or other maintainers, or make it possible to easily trick people to encrypting data to keys that are not really ours.

I sign 100% of my commits, and 100% of all artifacts I maintain etc. Anyone claiming to be me on anything important without signatures from my very well established and easy to verify public keys, are not me.

A PGP key is the only standardized cryptographic passport for the internet and if you don't attach your work to an easily verifiable key you are one compromised account away from having your online identity used for supply chain attacks.

All major linux distributions and the core infrastructure on the internet is anchored in the PGP keys of few thousand people that put in the work to maintain well published keychains.

The only alternatives anyone have proposed are use Fulcio and let Google sign everything for you as a single point of failure for the internet. Hard pass.

Meanwhile with solutions like keyoxide, anyone can form confidence my key is mine trivially without relying on a central party:

https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA...

Re: Switching from GPG to Age

#73

Post by johnisgood »

akerl_ wrote: post #67
rmunn wrote: post #43

Earlier quoted context omitted.

It allows the security guy (in this case, zikduruqe) to send an email that can only be read by the person who possesses the corresponding private key. Which means that either the email is going to the executive who really does own the account, or else that the attacker has already breached that executive's laptop to the point of having acquired his private key (and passphrase, if there was one), in which case phishin…

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 giving me what I wanted. How do you have any idea that I’m the person I said I am?

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?

Re: Switching from GPG to Age

#74

Post by johnisgood »

Vegenoid wrote: post #68
tptacek wrote: post #64

Earlier quoted context omitted.

He's asking how this procedure learns which public keys are trustworthy, not how asymmetric cryptography works.

I think what I’ve gathered is that the person I replied to is going with a TOFU model of key security (trust on first use), or is just seeking to avoid plaintext passwords in slack messages and is treating the key as disposable for the one-time encryption of the password. Presumably they must trust that the user messaging them on slack is indeed who they say they are and is in control of the account. If I’ve understo…

Like I have said in another comment, the question of identity verification makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme.

See: https://news.ycombinator.com/item?id=45919561

Re: Switching from GPG to Age

#75

Post by akerl_ »

johnisgood wrote: post #73
akerl_ wrote: post #67

Earlier quoted context omitted.

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 giving me what I wanted. How do you have any idea that I’m the person I said I am?

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

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.

Re: Switching from GPG to Age

#76

Post by johnisgood »

akerl_ wrote: post #75
johnisgood wrote: post #73

Earlier quoted context omitted.

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

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

Re: Switching from GPG to Age

#77

Post by tptacek »

johnisgood wrote: post #74
Vegenoid wrote: post #68

Earlier quoted context omitted.

I think what I’ve gathered is that the person I replied to is going with a TOFU model of key security (trust on first use), or is just seeking to avoid plaintext passwords in slack messages and is treating the key as disposable for the one-time encryption of the password. Presumably they must trust that the user messaging them on slack is indeed who they say they are and is in control of the account. If I’ve understo…

Like I have said in another comment, the question of identity verification makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme. See: https://news.ycombinator.com/item?id=45919561

That is an extremely weird argument. They aren't separable concerns. If you have a trusted identity in place you could use a password-protected AES ZIP file for all the encryption matters.

Re: Switching from GPG to Age

#78

Post by tptacek »

lrvick wrote: post #69
tptacek wrote: post #59

Earlier quoted context omitted.

It has not at all been my experience that PGP-encrypted bounty submissions are fast-tracked and most (almost all, in fact) good bounty submissions aren't encrypted. Google downplays PGP in the link you provided. Apple doesn't ask people to use theirs.

Are we looking at the same links? It is provided as an option, the ONLY option, for those that feel encryption is merited for a sensitive report. Google page: "If you feel the need, please use our PGP public key to encrypt your communications with us." Apple page: "Apple security advisories are signed with the Apple Product Security PGP key. Sensitive security information may be encrypted to this key when communicati…

I think you missed some subtext that I thought was pretty obvious which is that most people don't encrypt bug bounty submissions in 2025.

Re: Switching from GPG to Age

#79

Post by lrvick »

tux1968 wrote: post #61
lrvick wrote: post #52

Earlier quoted context omitted.

Just to name a few of the projects I work on, use, or find most interesting: https://keyoxide.org/ https://git.distrust.co/public/keyfork https://git.distrust.co/public/airgap https://codeberg.org/heiko/openpgp-pkcs11 https://codeberg.org/openpgp-card/openpgp-card-tools https://sequoia-pgp.org/ https://github.com/rpgp/rpgp https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-... https://doc.qubes-os.org/en/lat…

It's hard to know how these pieces fit together, especially if you have a fuzzy mental-model of the objectives and potential benefits. Is there a gentle introduction you'd recommend?

There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools.

For most individuals seeking to establish a long term durable personal keychain they want others to be able to externally trust and verify easily, I would suggest the following, which is more or less what most people in my circles do:

1. Buy a smartcard with touch support such as a Nitrokey 3

2. Ideally buy 3+ backup smartcards at the same time

3. Use Keyfork on AirgapOS booted on a laptop you trust to generate a 24 word mnemonic and split-encrypt it to 3+ smartcards (or write down mnemonic on paper if you lack budget for 3 extra smartcards)

4. If using backup smartcard set, split them up across 3 secure locations, or if using a raw mnemonic put on durable storage such as cryptosteel, and put that in tamper evident storage such as in a vacuum sealed bag with confetti with pictures you have copies of elsewhere.

5. Use keyfork to derive a PGP key and load it into your smartcard

6. Setup forced/locked "touch" requirement policies on all "slots" on your card so you must tap for each use (malware cannot do this, but easy for you to do)

7. Publish public key to keys.ogenpgp.org

8. Publish public key on your own domain name using Web Key Discovery

9. Use keyoxide docs to establish keyoxide profile with every internet platform you control attesting your key fingerprint is yours to make it easy for others form confidence that all of those are you, and your key is yours.

10. Major bonus: use QubesOS and map your smartcard only to an offline vault VM that prompts you for each use, and which security domain on your system wants to use your key, so malware is unlikely to be able to trick you even if your development environment is compromised.

From there you can use your provisioned smartcard with an openpgp smartcard capable ssh agent on your workstation for git signing, git push, ssh to servers, password management with password store, signing artifacts, thunderbird for email encryption, etc.

We plan on writing up a lot more public documentation for this sort of thing as the public docs suck, but we have helped thousands of people with this sort of thing.

Pop into #!:matrix.org or #keyfork:matrix.org if you want any help or advice for specific use cases.

A partially complete set of docs for different threat models is in progress at https://trove.distrust.co

Re: Switching from GPG to Age

#80

Post by johnisgood »

tptacek wrote: post #77
johnisgood wrote: post #74

Earlier quoted context omitted.

Like I have said in another comment, the question of identity verification makes no sense in this context. The identity verification problem is orthogonal to the encryption scheme. See: https://news.ycombinator.com/item?id=45919561

That is an extremely weird argument. They aren't separable concerns. If you have a trusted identity in place you could use a password-protected AES ZIP file for all the encryption matters.

There are too many threads, see: https://news.ycombinator.com/item?id=45919651. I don't see why we got here from PGP though.

> I think I'm missing something, how does asking for their public key improve security or verify their identity?

OK, so this was the question. My response should have been "it does not necessarily verify their identity". I mentioned some of the mechanisms for identity verification in the other thread.

Post reply on HN