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

31–40 of 148 posts

Re: Switching from GPG to Age

#31

Post by networked »

> I'm now experimenting with `age`, which touts itself as "simple, modern, and secure encryption". If needed, I will use `minisign` for signatures.

I have also switched from GPG to age. When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too. I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616). GitHub supports it in the sense that it will indicate a commit or tag is signed. I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).

gpg-agent was valuable to me because it let me use `pass` in scripts while maintaining encryption at rest. This prevented me from switching to `passage`. After surveying my options (https://github.com/dbohdan/pago/blob/6aa312e83113498a64abd9a...), I ended up forking pash (https://github.com/dylanaraps/pash) and developing the fork into an age-based password manager with its own agent. The developer of seniorpw has a nice feature comparison of `pass`-like password managers based on age (https://gitlab.com/retirement-home/seniorpw/-/blob/f1584cf42...).

I can say I am happy with the switch. If you use GPG for encrypting files, I can recommend it.

Re: Switching from GPG to Age

#33

Post by lrvick »

tptacek wrote: post #30
lrvick wrote: post #29

Earlier quoted context omitted.

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

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.

I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well.

As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems and hardware security modules for several large financial institutions and hundreds of billions of dollars of infrastructure, and have worked closely with many cryptographers who review our work, and the supply chain security engineers responsible for signing commits, packages, and reproducible builds for major linux distributions including the one I founded.

All of the above relies on PGP smartcards for signed commits, commit pushes, ssh, signed reviews, trust bootstrapping, because no other tooling or spec has that covered with multiple competing implementations to choose from as well as PGP.

The only fair point in the article still relevant today IMO is forward secrecy but any tooling that really needs that like an instant messenger would use ciphers and protocals designed for that. PGP would just be used as an identity CA to bootstrap trust in those cases if anything.

Re: Switching from GPG to Age

#34

Post by fsmv »

lrvick wrote: post #13

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…

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.

Re: Switching from GPG to Age

#35

Post by lrvick »

fsmv wrote: post #34
lrvick wrote: post #13

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…

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.

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.

Re: Switching from GPG to Age

#36

Post by Vegenoid »

zikduruqe wrote: post #23
johnisgood wrote: post #21

Earlier quoted context omitted.

Thank you for your comment. For a minute I thought I was going insane because there is no way that GPG/PGP is used only by the minority. Literally everyone uses it, even non-techies. phew > any engineering role where security matters that is -not- using PGP smartcards to sign and push their commits, sign code reviews, sign build reproductions of container images, encrypt their passwords, etc. I agree. Even without sm…

Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key". They do not get their credentials until they do so. And once they do, our security posture gets better and better.

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

Re: Switching from GPG to Age

#37

Post by networked »

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 [Alt text: A terminal window. The classic recipient on the first line takes about 2/3 of a line. The PQC one takes 16 lines.]

Re: Switching from GPG to Age

#38

Post by tptacek »

lrvick wrote: post #33
tptacek wrote: post #30

Earlier quoted context omitted.

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.

I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well. As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems…

I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread).

When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.

How do you respond to the PGP format points raised in that post? How do you respond to the prevalence of the MDC construction?

Re: Switching from GPG to Age

#39

Post by jcgl »

lrvick wrote: post #35
fsmv wrote: post #34

Earlier quoted context omitted.

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.

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…

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

Re: Switching from GPG to Age

#40

Post by lrvick »

tptacek wrote: post #38
lrvick wrote: post #33

Earlier quoted context omitted.

I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well. As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems…

I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread). When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. How do you respond…

> When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing.

I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to.

The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed today, and has a lot of legacy ciphers that should never be used anymore that modern tooling must not expose, etc. But also, that re-inventing very widely used and established standards and tools that are secure enough for those use cases is rarely worth it.

PGP is the bootstrap trust layer for the internet, governments, linux distros, and critical infrastructure all over the world and it is not going away, so might as well take advantage of the compatibility wins of modernizing it.

We would have designed HTTP and TLS and the internet as a whole a -lot- differently today too. They are broken as hell but the job is to improve and upgrade even when it would be more fun to start over. In hindsight, everything is shit. But I am not about to try to make a new internet and convince people to use it. That is more complex to do than living with and working around the early dumb design choices when they can be made secure.

We do not just abandon HTTP and TLS, we navigate early awkward choices and we debate and iterate on new versions of standards. Similarly, many teams including mine, put in the work to modernize PGP tooling, and the OpenPGP working group still exists and still iterates on the standard (Though admittedly not as much as many of us would like).

As for MDC, another thing that is awkward, but good enough: https://articles.59.ca/doku.php?id=pgpfan:mdc

It is my general opinion that for all the faults of PGP, it is still the best personal cryptographic identity anchored encryption and signing solution we have, especially when combined with smartcards and keyoxide. From there a rich ecosystem of tooling builds on top of that.

PGP (with modern tooling and ciphers) is much more sensible to recommend overa fragmented set of one trick tools with no key discovery, validation, or backup strategy that are bound to leave users with lost, stolen, or impersonated keys.

Post reply on HN