back
5 comments
OpenPGP is a standard, and a very flexible one. Not all implementations need to support all features. You cannot compare it to something like AGE, which is simply a single implementation without any effort to turn it into a standard about anything, nor the goal to support various use cases. We could go on talking about the differences of approach and the benefits and drawbacks of standardization, flexiblity, libraries vs. end-user applications etc, but that's been discussed times and times again here and elsewhere. There is simply no alternative to OpenPGP the standard and its efforts. Or can you point us at one?

Have you looked at the OpenPGP spec? I find it pretty readable, and you will quickly see how it cannot be compared to any single application.

I understand that AGE also has a "spec". It is limited to a single use case, encryption. No signatures, no certifications, no thoughts on key discovery or trust, etc etc.

The track record of cryptographic standards is one of pretty much unbroken failure; it's like the cryptography engineering version of "I'm from the government and I'm here to help".

It get worse when you take a close look at the standards process and see how standards bodies metabolize input from actual cryptographers. For a good time, check out how the IETF did with Phil Rogaway and IPSEC.

OpenPGP is a standard, and a very flexible one.

That's pretty much what makes it the opposite of 'modern cryptography'.

It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement.

There's no way that any non-flexible cryptography can ever stay modern if it doesn't accommodate for various key sizes and algorithms. If for no other reason, because we continue to see more and more compute power that makes brute forcing smaller or weaker keys more feasible.

Perhaps you can elaborate a bit more.

The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.
Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.
The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.
You will find disagreement only if you deliberately choose words like "brittle". The word you want is "simple". Crypto protocols need to be simple, to reduce attack surfaces.

"Flexible" protocols are the ones that are actually "brittle" -this is where the use of metaphorical language breaks down. "Flexibility" actually just introduces more places to break.

It is by now well accepted that modern crypto protocols should, in fact, be simple, and you will NOT find much disagreement with this.

Sadly age is only tackling one of the easier parts of gnupg, encrypting files. Implying age replaces gnupg is overselling it.

We don't have any good alternatives for a web-of-trust (or something akin) where we can sign files or attest trust to some identity. Signify does parts of this, but lacks the trust aspects which makes you establish convoluted key distribution schemes to ensure you have future signing keys lined up.

There isn't any good replacements for F/OSS developers that needs to have some from of signatures between them. Say replace linux distributions usage of signatures to form some network of developer trust.

PGP keyservers don't support the web of trust any more either.
There are some ideas for restoring support for the web of trust, not sure if they got implemented yet though:

https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistan... https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystor... https://lwn.net/Articles/792674/

Which is why most distributions and other projects has moved to WKDs for key discovery. I don't think this is a good argument though as there are alternatives, even though they don't work super well at the moment.
> Which is why most distributions and other projects has moved to WKDs for key discovery.

Yeah, WKD is a first-class citizen in GnuPG. Creating signatures with "--sender $EMAIL" embeds e-mail in the signature and then gpg --auto-key-retrieve --verify will fetch the key via WKD without the need to touch keyservers.

Modern cryptographic tools are very purposefully “one tool, one use.” That’s part of the design and security model.
Which makes the problem harder to solve. But this isn't an argument against the functionality though? It's still something we need if the community wants to move away from GnuPG.

What are the alternatives? PKCS7? I don't see that being less complicated then gnupg when it comes to usage. I think Void Linux is using this though, however you are still stuck without a proper way to assign trust.

Are you claiming that the Sequoia implementation of the OpenPGP standard is a "complicated old mess"? Because the OpenPGP standard (RFC 4880) isn't really all that complicated. A significant portion of is a bit by bit description of the key format.

At any rate, age is hardly any sort of replacement for OpenPGP. It is really only suitable for the case where you want to encrypt something like a backup and not bother to sign it. I am not really sure that it is superior even for that niche case. Most people would want to know a backup is corrupt before they started the restore, not partway through it.

> Most people would want to know a backup is corrupt before they started the restore, not partway through it.

Yes, which often makes OpenPGP a bad choice, because of how it has to authenticate things (requiring multiple passes). Many implementations of OpenPGP will happily release unauthenticated plaintext to the caller (and then fail at the end when the MAC fails- too late if you piped that to tar!) - there isn't an efficient way to do better than this with OpenPGP, because...well, it isn't very good.

In the out of scope section of the spec:

> Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones)

Yeah, they could implement it, but why not keep the utilities small and specific to a use case. You can shasum over the backup and sign it if that's what you want.

Pasting raw key material is so nice, Age is not even alpha featurewise. Stop recommending stuff that you don't use yourself.

$ age-keygen -o key.txt Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p $ tar cvz ~/data | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p > data.tar.gz.age $ age -d -i key.txt data.tar.gz.age > data.tar.gz

No.