It would be fantastic if Age (or at least something similar) could become standard on Unix machines. I'd love a more Unix-philosophy following tool than GPG/PGP to be around for encryption. That said, I don't think new standard tools for Unix machines are very common. The closest thing I can think of in the last while is `jq`, but it's not "preinstalled on your machine" kind of standard, just "my script might just use it and expect you to have it" kind of standard.
People might assume you have ripgrep, or fd, I suppose?
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.)
Isn't POSIX userspace mostly standardized? We should be pretty conservative with what goes into such a standard, but something like age and jq IMO meet that level of utility to justify it.
Yeah POSIX standardizes a bunch of tools, mostly the ones you'd expect (cut, cat, file, etc). I agree with the conservative standardization for the most part, but I selfishly would love these more niche tools to be available on a fresh box. Good point though, I just want to be a little lazier in my script writing I guess :)
I guess distros are the next layer over POSIX standard. Distributions have the ability to, mostly arbitrarily, select the default packages they ship in their releases.
Chicken and egg problem. People use sh/bash because it is everywhere and standard. Requires energy to justify using an objectively superior tool if it is not default installed.
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.
Doing one thing and doing it well is all and good, but most people are not interested in having to manually mess around with up to 4 raw keys in the pursuit of that. That's particularly true if you are doing pipes and you don't have any good place to put all those keys.
This is a little vacuous. Why are you signing? Why are you encrypting? Those are different operations. What are you trying to accomplish? The biggest problem with PGP is that its most popular use cases tend to be people bodging this old clanking command line tool into cryptosystems that (a) PGP wasn't designed for and (b) purpose-built cryptosystems are much better at.
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.
