UX: separate public/private key files

[sebastianv89]

What were you trying to do

Sharing the public key.

What happened

I needed to open the file and copy-paste the public key characters in order to share the public key. Having a separate file for the public key would make it more easy for me to share using standard tools, avoids copy-pasting user errors and avoids shoulder surfing issues.

[cyb3rz3us]

Maybe try something like:

age-keygen > agetest; grep public agetest > agepub

cat agetest

# created: 2020-01-09T18:28:34-08:00
# public key: age17kxecskhac5vmugtlk2yzucfe708a24c0c5evaehpxdn06rsd5lqdwh3rs
AGE-SECRET-KEY-1RHADQ2S305W63TMGDJ90DDF4QX80HZUDHVNGEQKAVHLA7QHHKHJSAA0TX4

cat agepub

# public key: age17kxecskhac5vmugtlk2yzucfe708a24c0c5evaehpxdn06rsd5lqdwh3rs

[sebastianv89]

Or even

age-keygen | tee age.sec | sed -n -e 's/^#public key: //p' > age.pub

but I'm still thinking this could be the default behaviour. Also consider that this becomes necessary when you want to encrypt the secret key (see also #86).

[FiloSottile]

The intention is for public keys to be copy-pasted or scripted, rather than always managed as files.

I should probably add an example for how to do that, like

PUBLIC_KEY=$(age-keygen | tee age.key | awk '/public key/{print $4}')

Likewise, you can easily redirect the public key to a file

age-keygen | tee age.key | awk '/public key/{print $4}' > age-public.txt

I should also cut a new beta with the age-keygen change that always prints the public key to stderr.

[meeDamian]

I like this:

$ age-keygen -o priv.key 2> key.pub

[downneck]

The intention is for public keys to be copy-pasted or scripted, rather than always managed as files.

seems onerous when compared to, say, ssh's path-based file search or gpg's string-based keystore search. curious as to what the motivation is for this UX vs. one of the others.

[cyb3rz3us]

Not seeing how being able to reference a file or paste a key directly is especially onerous. I would agree if users were forced into one option or the other might be but because both options, we have the best of both worlds.

[alerque]

@cyb3rz3us Having both keys stuffed in one file by default is unsafe. It means you DON'T have both worlds, the user is expected to copy the public key and not share it by sending a file. In order to send the public key as a file the user is expected to carefully extract the public data from the private key file. This _can_be done with the right shell commands, but why expect people to know how to get that right?

[Fastidious]

Wouldn't it be easy to add an option to age that would parse the keys file, and print just the public key?

[cyb3rz3us]

Ok so this thread is getting OT a little...but regardless...

"...why expect people to know how to get that right..."

Because I do expect people to be able to read a manpage, help page, manual, whatever...and get it right. If something is undocumented or behaves counter to what is documented, then agreed...not the user's issue. But when it is documented and behaves as such, then not sure what more one needs...RTFM really is very appropo most times.

Next, "...both keys stuffed in one file by default is unsafe..."

Not really...what is unsafe is not properly securing one's key files which includes not sending them to unintended recipients. This thread is discussing making sharing the public key easier...not a security issue. At present, the user can easily create a separate public keyfile albeit with a little more typing. I do see the merit to the feature ask --- and agree it makes 'age' easier on the end-user --- but I also firmly believe users need to take their own opSec seriously --- i.e. don't send out things improperly.

[downneck]

then not sure what more one needs

a better, smoother, inherently safer user experience...which is the entire point of this issue

[cyb3rz3us]

Again with the "inherently unsafe"...know your tools and stop blaming the app...

[sebastianv89]

Again with the "inherently unsafe"...know your tools and stop blaming the app...

The same could be said about PGP

[downneck]

instead of arguing about it more, I just wrote the functionality I was talking about. see #104

[cyb3rz3us]

There was no argument about the merits of the feature (read comments completely) - there was debate as to whether or not the current implementation is secure or burdensome to use...

[FiloSottile]

I don't think we'll make age-keygen generate multiple files, as the default intended UX involves simply copy-pasting the short recipient, but age now supports -R for recipient files, and I opened #250 to support converting an identity file into the corresponding recipients file. (Also note that -e -i is also now supported to encrypt directly to an identity file if it's available.)