11–20 of 60 posts
It would be better if the age specific code could be included upstream. This should, however, serve as a good point of reference.
No thanks, I'll stick with GnuPG.
I tried reading up on what age is, but I'm getting a cert error from their website: https://age-encryption.org/
I tried reading up on what age is, but I'm getting a cert error from their website: https://age-encryption.org/
I wrote a short blog post comparing PGP and Age a few weeks ago. Some may find it of interest: https://www.go350.com/posts/age-file-encryption/
One thing that wasn't mentioned is whether or not private keys can be stored in HSMs with age. I'm guessing since the authors recommend against password-protecting private keys that the answer is "no" but that's one reason that I pick GPG for things.
I wrote a short blog post comparing PGP and Age a few weeks ago. Some may find it of interest: https://www.go350.com/posts/age-file-encryption/
Thanks for that. One thing that wasn't mentioned is whether or not private keys can be stored in HSMs with age. I'm guessing since the authors recommend against password-protecting private keys that the answer is "no" but that's one reason that I pick GPG for things.
For example, https://github.com/str4d/age-plugin-yubikey makes it very easy to use PIV tokens, including YubiKeys, with age. (Well, for now with rage, since plugin support is coming in age v1.1.0.)
I argue against password-protecting keys by default because, unlike using hardware tokens, it doesn't protect against many threat models.
Earlier quoted context omitted.
The main argument in favour of age is that it only does one thing: encrypting files, and does it 'well' in the sense there is no need to edit your gnupg config file to exclude all the crypto from the 90s that your version of gnupg might decide to default to. This makes things significantly simpler in terms of the code for age, which reduces the possible bugs and possible misuse. GnuPG is more versatile and tries to s…
>...while GnuPG can be convinced to decrypt CAST5 encrypted messages... That's not actually a problem. The problem would be if it could be convinced to encrypt CAST5 messages. Assuming that is actually a problem. Is there anything particularly wrong with CAST5 other than the block size?
I don't disagree, but would add that if the encryption used is believed to be insufficiently secure these days all tools should warn loudly that this is the case when asked to decrypt them.