Hacker News Reader

> I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent.

The entire point of every single valid criticism of PGP is that you cannot make a single functionally equivalent alternative to PGP. You must use individual tools that are good at specific things, because the "Swiss Army knife" approach to cryptographic tool design has yielded empirically poor outcomes.

If you have an example of how age broke for you, I think its maintainers would be very interested in hearing that -- I've been using it directly and indirectly for 5+ years and haven't had any compatibility or runtime issues with it, including when sharing encrypted files across different implementations of age.

Point of order: there are valid and important criticisms of PGP that have nothing to do with its jack-of-all-trades philosophy. There's no modern cryptosystem in the world you would design with PGP's packet scheme.

Yeah, that was just the low-hanging fruit I reached for.

(I think you can make a tie-in argument here, though: PGP's packet design and the state machine that falls out of it is a knock-on effect of how many things PGP tries to do. PGP would maybe not have such a ridiculously complicated packet design if it didn't try and do so many things.)

> Apart from the fact that it really slowed down my deployments, the thing broke within a year. And I didn't even use it. I just wanted to see how reliable it will be in the most minimal of ways: by having it auto-installed on my systems.

I'm very curious about this. Tell me more.

I didn't even catch this the first read. `age` is a command line program written in Go. It's not a system service. Simply "having it installed" on your system can't do anything.

If it fails to build when the system is updated?

Poster says:

> slowed down my deployments

I take that to mean the _deployment_ step, not the deployed system.

There is a downloadable binary, I doubt many people recommending age are recommending every server using it also download a Go compiler and build it themselves.

What I meant was that the ansible recipe for building and installing age broke within a year. I didn't investigate why, I just switched it off, but it was a data point.

Yes, I know this can surely be explained and isn't a "fair" comparison. But then again my time is limited and I need predictable, reliable tools.

> Apart from the fact that it really slowed down my deployments

Is this a comparable complaint worth mentioning, and if it is are you sure you actually need cryptography? It slowed things down a bit, so you don't really want to move on from demonstrably too-complex to not have bugs GnuPG?

Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.

Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.

You want special purpose tools. Signal for communication, Age for safer file encryption, etc.

What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself? Age has yubikey support and can do all you described.

> if your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.

This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.

Downgrade protection, malleability protection, sidechannel protection, disambiguation, context binding, etc...

You want software to be implemented by experts using known best practices with good algorithms and audited by other experts.

If you haven't checked out sequoia (sq), you should! I think it ticks your boxes.

https://book.sequoia-pgp.org/about_sequoia.html

There's something to be said perhaps for preferring tools that do one of those things, rather than all of those things, and doing them well.

Not to say you can't then make an umbrella interface for interacting with them all as a suite, but perhaps the issue has become that gpg has not appropriately followed the Unix philosophy to begin with.

Not that I've got the solution for you. Just calling out the nature of your demands somewhat being at odds with a key design principle that made Unix and Unix-likes great to begin with.

There isn't an alternative that is functionally equivalent because what PGP does is dumb. It's a Swiss Army Knife. Nobody who wants to design an excellent saw sets out to design the Swiss Army Knife saw[†]. Nobody who needs shears professionally buys a Swiss Army Knife for the scissors.

The cryptographic requirements of different problems --- backup, package signing, god-help-us secure messaging --- are in tension with each other. No one design adequately covers all the use cases. Trying to cram them all into one tool is a sign that something other than security is the goal. If that's the case, you're live action roleplaying, not protecting people.

I'd be interested in whether you could find a cryptographer who disagrees with that. I've asked around!

[†] I am aware that SAK nerds love the saw.

So what toolbag or workshop of excellent specialized tools would provide the same capability as GnuPG?

Ask me a question about a specific realistic problem (ie, not "how do I replicate this behavior of PGP", but rather "how do I solve this real-world problem") and I'll give an answer (or someone else will).

I think I described (though perhaps too briefly or not clearly enough) the very specific realistic problems?

I'm somewhat amused that every time this kind of discussion comes up, the answer is "you are holding it wrong". I have a feeling the world of knowledgeable crypto folks is somewhat detached from user reality.

If a single tool isn't possible, give me three tools. But if those three tools each require separate sets of keys with their own key management systems, I'm not sure if the user's problem is being addressed.

Which three problems? This isn't a trick question.

I only counted one problem:

> I want to be able to encrypt my backups to multiple recipients.

Presumably this means you want to encrypt the backup once and have multiple decryption keys or something?

The rest of your original comment are constraints around how you want it to work.

I believe all the criticism of GnuPG is due to the fact most people grew up with Microsoft or Apple, so they are use to hand-holding.

If you read the various how-tos out there it is not that hard to use, just people do not want to read anything more than 2 lines. That is the main issue.

My only complaint is Thunderbird now uses its own homegrown encryption, thus locking you into their email client. Seems almost all email clients have their own way of encryption, confusing the matters even more. I now use mutt because it can be easily likned to GnuPG and it does not lock me into a specific client.

> If you read the various how-tos out there it is not that hard to use, just people do not want to read anything more than 2 lines. That is the main issue.

The video linked above contains multiple examples of people using GnuPG's CLI in ways that it was seemingly intended to be used. Blaming users for holding it wrong seems facile.