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

51–60 of 148 posts

Re: Switching from GPG to Age

#51

Post by lrvick »

justincormack wrote: post #47
lrvick wrote: post #46

Earlier quoted context omitted.

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

All the docs encourage you to use a different ssh key for signing I think; certainly I do.

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.

Re: Switching from GPG to Age

#52

Post by lrvick »

somat wrote: post #50
lrvick wrote: post #46

Earlier quoted context omitted.

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

So just out of curiosity, what is this modern tooling? It was brought up previously in this thread without naming any names.

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/latest/user/security-in-qubes/sp...

Re: Switching from GPG to Age

#53

Post by knorker »

aborsy wrote: post #16
knorker wrote: post #9

Is it post-quantum yet? I could not find indications of that.

It uses key files that are 128 bits. With symmetric encryption, it’s equivalent to AES-128, so not really post quantum. It has post quantum plugins, but those are third party plugins!

Yeah 128bit for symmetric is not enough, but it uses public key cryptography, right?

"RECIPIENT can be an age public key generated by age-keygen ("age1...") or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...")."

Re: Switching from GPG to Age

#54

Post by knorker »

aidenn0 wrote: post #32
knorker wrote: post #9

Is it post-quantum yet? I could not find indications of that.

Is quantum computing a major issue for symmetric keys? I thought it was primarily an issue with public-keys?

The File Key is symmetric, but the header having recipient implies this is public key crypto.

So break the public key crypto (e.g. X25519), and you don't need to crack the symmetric key.

Also 128 bit? That's not quantum safe either, thanks to Grover's algorithm.

Re: Switching from GPG to Age

#55

Post by knorker »

networked wrote: post #37
knorker wrote: post #9

Is it post-quantum yet? I could not find indications of that.

No. age developer Filippo Valsorda has experimented with Kyber/ML-KEM and maintains a Go library for it, https://github.com/FiloSottile/mlkem768 . The public key size is intimidating. https://x.com/FiloSottile/status/1544803635237998592 (2022-07-06): > A Kʏʙᴇʀ768+X25519 recipient would clock in at about 1660 characters. > Classic X25519 age recipient for scale. > https://paste.dbohdan.com/1mhc0nc-w7ks3/recipient.png…

Oh, that's a shame.

I'd like to use something stable and supported for long term backups, so size doesn't matter. Pre-quantum is not something worth migrating to.

Re: Switching from GPG to Age

#56

Post by lrvick »

tptacek wrote: post #26
lrvick wrote: post #15

Earlier quoted context omitted.

By very small niche group, you mean every maintainer of every widely used production linux distribution and most of the core packages that form the supply train trust layer for the entire internet? Or every reasonably competent security vulnerability disclosure team? (Even Google and Apple!) PGP is the only standardized cryptographic online identity layer we have and still very heavily used by anyone working on secur…

Neither Google nor Apple rely on PGP for vulnerability disclosure handling. Lots of organizations publish a PGP key, but in practice rarely use them.

Citation needed.

Both Apple and Google have updated these pages with security disclosure PGP keys in the last year.

https://support.apple.com/en-us/101985

https://about.google/company-info/appsecurity/

I design most corporate bug bounty programs the same way.

Sure, people rarely use PGP, but the ones that do are usually serious and high quality, and we let them skip the tier 1 queue. Script kiddies never know how to encrypt things.

Re: Switching from GPG to Age

#57

Post by epistasis »

lrvick wrote: post #51
justincormack wrote: post #47

Earlier quoted context omitted.

All the docs encourage you to use a different ssh key for signing I think; certainly I do.

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…

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://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

Re: Switching from GPG to Age

#58

Post by tux1968 »

lrvick wrote: post #51
justincormack wrote: post #47

Earlier quoted context omitted.

All the docs encourage you to use a different ssh key for signing I think; certainly I do.

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?

Re: Switching from GPG to Age

#59

Post by tptacek »

lrvick wrote: post #56
tptacek wrote: post #26

Earlier quoted context omitted.

Neither Google nor Apple rely on PGP for vulnerability disclosure handling. Lots of organizations publish a PGP key, but in practice rarely use them.

Citation needed. Both Apple and Google have updated these pages with security disclosure PGP keys in the last year. https://support.apple.com/en-us/101985 https://about.google/company-info/appsecurity/ I design most corporate bug bounty programs the same way. Sure, people rarely use PGP, but the ones that do are usually serious and high quality, and we let them skip the tier 1 queue. Script kiddies never know how to…

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.

Re: Switching from GPG to Age

#60

Post by tptacek »

lrvick wrote: post #49
tptacek wrote: post #42

Earlier quoted context omitted.

Are you sure you want to be citing that particular site to defend the MDC? Do you co-sign other things it says? https://articles.59.ca/doku.php?id=pgpfan:index Anyways, at this point my feeling is that you've essentially conceded the actual point I was making (that PGP is itself also a shitshow of 1990s cryptography), and answered that you just don't care that it is. That's a perfectly coherent point to make and not…

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 claim, and it was false in an important way, and it has now been falsified.
Post reply on HN