[HN Gopher] Passage: A fork of password-store that uses age inst...
___________________________________________________________________
Passage: A fork of password-store that uses age instead of GnuPG
Author : Shank
Score : 43 points
Date : 2021-12-17 20:10 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| creamytaco wrote:
| No thanks, I'll stick with GnuPG.
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| jrootabega wrote:
| I'm guessing you probably have something say about the
| criticisms of GnuPG, which would be good to talk about IMO.
| aranw wrote:
| Why stick with GnuPG?
|
| I'm also interested in trying to understand why use age instead
| of GnuPG?
| zahllos wrote:
| 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.
| upofadown wrote:
| >...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?
| hkt wrote:
| Not going to use it (I already use pass) but this is great and
| I'm glad there is another option out there for people.
| atweiden wrote:
| See also: https://git.sr.ht/~gpanders/passage
| endymi0n wrote:
| > 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...
| ayushnix wrote:
| It would be better if the age specific code could be included
| upstream. This should, however, serve as a good point of
| reference.
| toomanymike wrote:
| 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
___________________________________________________________________
(page generated 2021-12-17 23:00 UTC)