UX: Encrypt private key by default

[johnalanwoods]

What were you trying to do

I was playing with the Age beta, generating keys

What happened

I think that in spite of solid UNIX file permissions, the default behaviour should be to encrypt private keys with a symmetric key derived from a password.

Is there an intention to add this feature to Age? If not how best should users. secure plaintext private key material?

Reading the document on Age I see:

Maybe native support for key wrapping (to implement password-protected keys)

However surely that's a fundamental need, otherwise private key material sits in plaintext.

[cyb3rz3us]

FWIW, I gen my keypairs using ssh-keygen but agreed that enhancing the age-keygen w/ encrypted private keys would be nice as long as not mandated.

[johnalanwoods]

@cyb3rz3us - that's a nice approach, so you get encrypted private keys, however, can you use the ssh-gen private key with age directly?

(if so I guess ok once it's an ed25519 key.

[cyb3rz3us]

can you use the ssh-gen private key with age directly

By all means. However, when encrypting using the 'age' keys (i.e. recipients), you will need to include the public key data on the command line. As you can imagine, this can become quite cumbersome especially for keys > 1024. The spec and 'age' help screen both discuss specifying the pub key as a file but it is apparently not yet working; there is a ticket open to get it working.

That said, this does work on the decrypt side --- the private key file can be specified using the '-i' switch and if the key is PW protected, then you will be prompted for the password.

once it's an ed25519 key

Not sure what you mean here? The payload en\decryption key is not generated by the keygen app...that is still done by 'age'.

[vext01]

However surely that's a fundamental need, otherwise private key material sits in plaintext.

I agree.

I'm trying hard to ditch gpg for something else. One contender is opmsg, but the lack of protection for private key material puts me off:

The private part of the keys which are stored inside ~/.opmsg are NOT encrypted. It is believed that once someone gained access to your account, its all lost anyway.

I disagree with the above. No one has gained access to my system, but I do run lots of software on my system, and any one of them may try to steal private keys.

[When I first looked at age, I had planned to simply use my SSH private key, but sadly it resides on a yubikey, which can't yet be used with age. So a regular encrypted age key might be a good stepping stone until ssh-agent support is integrated. Agent support would be ideal though, as I'd only have to unlock the private key once.]

[infa-jowoods]

Would @FiloSottile take a PR on this? I'm happy to take a stab at it.

[vext01]

There's one linked above, but it seems to have stalled.

[codesoap]

I, too, like to encrypt my keys most of the time, but I can also see how implementing this here would hurt the simplicity of age. age already provides all features to create password-secured keys ourselves (since #173 it's even easier). This is how it could work:

$ printf 'foo\n' > testdata
$ age-keygen | age -p -o mykey.age
Public key: age1j85xmnxgavcach38x4nnzu2tcmdnj7vqq2d4ffmwjsdh9flcuy9sa8agsm
Enter passphrase (leave empty to autogenerate a secure one): mysecret
Confirm passphrase: mysecret
$ age -o testdata.age -r age1j85xmnxgavcach38x4nnzu2tcmdnj7vqq2d4ffmwjsdh9flcuy9sa8agsm testdata
$ age -d mykey.age | age -d -i - testdata.age
Enter passphrase: mysecret
foo

This also has another advantage: It's easy to extract your non-password-protected key. This can be useful if you want to store it with gfshare or similar. After that, forgetting your password will not make your encrypted files useless, but it's still not easy for an attacker to steal your key.

[Fastidious]

@codesoap, is there a way to save output on decryption instead of STDOUT? I know one can do:

age -d mykey.age | age -d -i - testdata.age > testdata

But I wonder if there is a way using the -o flag. I tried a few combinations unsuccessfully.

[CHTJonas]

is there a way to save output on decryption instead of STDOUT? [...] I wonder if there is a way using the -o flag. I tried a few combinations unsuccessfully.

Weird. Using -o works fine for me:

age -d mykey.age | age -d -i - -o testdata.2 testdata.age