Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passage: A fork of password-store that uses age instead of GnuPG

github.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Passage: A fork of password-store that uses age instead of GnuPG

#21

Post by johnisgood »

zahllos wrote: post #9
aranw wrote: post #4

Earlier 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…

> 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 remember was being the followed practice (it uses GC anyways), in fact, I remember copying like no tomorrow. Correct me if I am wrong though. Regardless, languages with GC are usually a no-no. There is a chapter on it in "Cryptography Engineering: Design Principles and Practical Applications by by Bruce Schneier, Niels Ferguson, and Tadayoshi Kohno", the name of the chapter is: "Implementation Issues". It mentions Java (as not being a good language for crypto due to GC), and I think C as well.

In any case, it has been a while, and I am currently tired. Feel free to correct me, of course.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#22

Post by srer »

aranw wrote: post #4
creamytaco wrote: post #2

No thanks, I'll stick with GnuPG.

Why stick with GnuPG? I'm also interested in trying to understand why use age instead of GnuPG?

I use pass, and have no desire to move away from gpg.

I think gpg still provides "pretty good" privacy, I don't see any benefit that age would afford me with pass.

(There are sore points to the OpenPGP user experience, integration with mail clients among others, along with the WoT, have in practice been not great. But these are not things you would encounter with pass.)

Re: Passage: A fork of password-store that uses age instead of GnuPG

#23

Post by jeremyw »

FiloSottile wrote: post #19
aidenn0 wrote: post #18

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…

Can you clarify re not password-protecting keys?

If I run GUI applications, let's say, as my user -- as is the default in most operating systems -- they have general access to my files, including my keys-as-files, no? (Putting aside some minor restrictions MacOS and others are slowly making.)

Re: Passage: A fork of password-store that uses age instead of GnuPG

#24

Post by srer »

zahllos wrote: post #9
aranw wrote: post #4

Earlier 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…

> ...edit your gnupg config file to exclude all the crypto from the 90s...

Personally, I would suggest leaving Rijndael (AES winner) in ;).

Re: Passage: A fork of password-store that uses age instead of GnuPG

#25

Post by FiloSottile »

jeremyw wrote: post #23
FiloSottile wrote: post #19

Earlier quoted context omitted.

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…

Can you clarify re not password-protecting keys? If I run GUI applications, let's say, as my user -- as is the default in most operating systems -- they have general access to my files, including my keys-as-files, no? (Putting aside some minor restrictions MacOS and others are slowly making.)

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend.

We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#26

Post by [deleted] »

jeremyw wrote: post #23
FiloSottile wrote: post #19

Earlier quoted context omitted.

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…

Can you clarify re not password-protecting keys? If I run GUI applications, let's say, as my user -- as is the default in most operating systems -- they have general access to my files, including my keys-as-files, no? (Putting aside some minor restrictions MacOS and others are slowly making.)

[deleted]

Re: Passage: A fork of password-store that uses age instead of GnuPG

#27

Post by jeremyw »

FiloSottile wrote: post #25
jeremyw wrote: post #23

Earlier quoted context omitted.

Can you clarify re not password-protecting keys? If I run GUI applications, let's say, as my user -- as is the default in most operating systems -- they have general access to my files, including my keys-as-files, no? (Putting aside some minor restrictions MacOS and others are slowly making.)

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend. We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

I suppose in a homebrew situation, but not if age is root-installed, correct? It seems like that's a hard boundary.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#28

Post by FiloSottile »

jeremyw wrote: post #27
FiloSottile wrote: post #25

Earlier quoted context omitted.

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend. We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#29

Post by jeremyw »

FiloSottile wrote: post #28
jeremyw wrote: post #27

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.

Fair enough. I believe I can mitigate enough of these to continue the utility of password-protecting my keys, but I take your point.
Post reply on HN