Ultimately, though, I think the importance of having a guarantee that the OS has the complete built-in 'swiss army chainsaw' (to borrow a Perl-ism) just isn't as high priority in the age of modern package managed, dependency graphed, fibre connected always online systems vs. big monolithic beasts that you maybe 'make install' the odd extra piece of software you heard about on usenet, once the 300 baud modem is done bleep-blooping out the source from the CVS repository. =P
That said, we do get new toys, right up to the kernel level; compression algorithms like zstd, hashing algorithms like xxhash, the slow & steady (glacial?) advance of BTRFS features...
If there is demand for something like age, you'd expect it'll filter through into the base of distros, become 'de facto standard', glom onto the kernel, etc. etc. like other stuff people find useful and want, no?
(Even if not, it's written in go, so... 'go install filippo.io/age/cmd/...@latest'? =d Issues aside, modern lang-specific package managers make it stupidly easy to grab software these days.)
I've always used this site as reference: https://pubs.opengroup.org/onlinepubs/9699919799/
That is one path to standardizing something - using it.
I would love if I could count on Just, fish, ripgrep, or any other multitude of tools that improve upon these CLI apis that were invented ad hoc and ossified in the 70s. Paved a lot of cow paths.
Most of the time you want to go:
gpg --sign --encrypt file
One of the reasons age is so constrained is that the problems best served by direct simple file encryption are quite narrow.
In any case I can think of, people encrypt things because they want to restrict who can know what those things are.
>Why are you signing?
In the context of encrypted files, you would sign because you want to know if an attacker has modified or more simply just replaced your file. Authenticated encryption is considered more or less standard these days.
>Those are different operations.
Except for niche applications like password storage, most people want/need authentication. Giving someone a raw encryption utility like Age is almost always going to result in a situation where that user is not protected against modification/replacement when they do asymmetrical encryption. That is assuming that they can figure out the keys for even just the encryption.
Well actually it does if the attacker does not have access to the decryption key ... which is very much the normal case. Yes, I know about "surreptitious forwarding" but I consider the idea silly in terms of usability[1].
>asymmetrical encryption is authenticated if you keep your recipient key a secret...
This is an expression of the idea that you can just keep the recipient identity (public key) away from the attacker and prevent them from creating a valid ciphertext. The fundamental issue is that this depends on a poorly specified property of the cryptography. Any protection against an attacker being able to derive the public key is merely accidental. The author of the linked article says:
>I am confident the property holds for the X25519 recipients, and that it would hold for a hypothetical Kyber768+X25519 one,...
... but provides no explicit argument to that effect. ... and then continues:
>...but it's important not to advertise it as an age-wide property.
In practice the recipient identity key will show up on the command line and/or will be kept in an unencrypted file. Age itself treats it as a potentially public value.
If you and the recipient have the ability to share and keep a secret value secret, why use asymmetrical encryption in the first place? Why not put that value in the plaintext as discussed previously in the article? The reason that there is not more research into the security of secret recipient identities is because there is no practical value in such use.