Passage: A fork of password-store that uses age instead of GnuPG
1–10 of 60 posts
Re: Passage: A fork of password-store that uses age instead of GnuPG
#2No thanks, I'll stick with GnuPG.
Re: Passage: A fork of password-store that uses age instead of GnuPG
#3It would be better if the age specific code could be included upstream. This should, however, serve as a good point of reference.
Re: Passage: A fork of password-store that uses age instead of GnuPG
#4No thanks, I'll stick with GnuPG.
Why stick with GnuPG?
I'm also interested in trying to understand why use age instead of GnuPG?
Re: Passage: A fork of password-store that uses age instead of GnuPG
#5Not going to use it (I already use pass) but this is great and I'm glad there is another option out there for people.
Re: Passage: A fork of password-store that uses age instead of GnuPG
#6No thanks, I'll stick with GnuPG.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
Re: Passage: A fork of password-store that uses age instead of GnuPG
#7See also: https://git.sr.ht/~gpanders/passage
Re: Passage: A fork of password-store that uses age instead of GnuPG
#8> 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/backends...
Re: Passage: A fork of password-store that uses age instead of GnuPG
#9No thanks, I'll stick with GnuPG.
Why stick with GnuPG? I'm also interested in trying to understand why use age instead of GnuPG?
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 solve a number of (arguably, orthogonal) problems, including signing and authentication (by users and also of keys in the web of trust). This leads to more complexity, and some parts, e.g. the web of trust, can't really be described as being a success. Others, such as sign and encrypt, likely don't achieve semantic security (also the case in SMIME / CMS, and I'm not sure if this has ever been fixed) and definitely don't achieve the forward/future secrecy guarantees of say Signal. Age isn't trying to be a messenger, so it doesn't need to worry about this.
It comes down to this: if you use AES-Something with GnuPG or you use ChaCha20-Poly1305 with Age, it is unlikely ever to be meaningfully broken in our lifetimes (including if you are currently 1 day old and including by quantum computers) and everything will be fine. But age will only use ChaCha20-Poly1305, and the format is pretty simple, while GnuPG can be convinced to decrypt CAST5 encrypted messages and has a much more complex format that introduces a greater risk of binary parser vulnerabilities.
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.
Re: Passage: A fork of password-store that uses age instead of GnuPG
#10Earlier quoted context omitted.
Why stick with GnuPG? I'm also interested in trying to understand why use age instead of GnuPG?
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?