31–40 of 60 posts
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…
> Age is written in Go (there's also Rage, written in Rust), whereas GnuPG is a big old ball of C, so if there are parser bugs, GnuPG is bad news and Go/Rust are likely hopefully sound. Well, on "written in Go" part, I remember looking at the crypto code 2-3 years ago (??), and it was full of unnecessary copies. You know the practice of using explicit_bzero, avoiding copying, and so forth? In this case neither I reme…
We need good GUI apps on multiple platforms for tools like this (and for tools like age/rage). It’s one thing to use such tools for oneself, but impossible to have many others adopt it if there’s no GUI.
It's a useful tool regardless of how widely it's used. Would it become better if others used it as well?
It would be better if the age specific code could be included upstream. This should, however, serve as a good point of reference.
Many useful patches are posted to the upstream pass mailing list. They're rarely responded to. I don't know if that specifically drove the creation of this fork, but it's absolutely a frustration as a pass user
Earlier quoted context omitted.
I suppose in a homebrew situation, but not if age is root-installed, correct? It seems like that's a hard boundary.
I mean, most users don't root-install, but anyway the GUI application can drop a different age binary higher on the user's PATH. Or change their shell. Or a million other things. There really isn't a point to defending against code running unsandboxed on a single-user machine.
Earlier quoted context omitted.
I mean, most users don't root-install, but anyway the GUI application can drop a different age binary higher on the user's PATH. Or change their shell. Or a million other things. There really isn't a point to defending against code running unsandboxed on a single-user machine.
I password protect my key for the sole threat model of me physically losing my device. I am aware that all other threat models that involve someone taking remote control of my device are not fully protected against, but it at least requires significantly more effort on their part versus just doing a scan for private keys on the file system.
> The age backend is an experimental crypto backend [for gopass] based on age. It adds an encrypted keyring on top (using age in scrypt password mode). It also has (largely untested) support for specifying recipients as github users. This will use their ssh public keys for age encryption. It is well positioned to eventually replace gpg as the default crypto backend. https://github.com/gopasspw/gopass/blob/master/docs…
Earlier quoted context omitted.
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.
We designed the plugin protocol ( https://hackmd.io/@str4d/age-plugin-spec ) and generally the age recipient/identity structure specifically to enable the use of hardware or remote keys! 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…
Stupid question: Are only YubiKeys supported or also other hardware tokens?