Age is a bit awkward if you want to store your private key encrypted.
$ age-keygen -o key
$ grep public key | cut -f ' ' -f 4 > key.pub
$ age -p -a -o key.prv key
(enter passphrase to protect private key)
$ rm key
OK, now we have key.pub with a copy of our public key, and key.prv with the private key encrypted with a passphrase.
Now suppose we receive a file, msg.sec, that was encrypted using our public key. If our key file were not encrypted, we could decrypt the message as so:
$ age -d -i key.prv msg.sec
With the private key encrypted, we need to decrypt it into a file, use the file with the above command, and then presumably get rid of the decrypted private key file. There are a few ways to do this on Unix and Unix-like systems.
1. Use an actual file.
$ age -d key.prv -o key.tmp
(enter passphrase)
$ age -d -i key.tmp msg.sec
$ rm key.tmp
I dislike this. What if something like Time Machine happens to take a snapshot right as I'm doing this, and key.tmp gets into the backup?
2. Use a named FIFO.
$ mkfifo f
$ age -d -i f -o msg msg.sec &
$ age -d key.prv > f
(enter passphrase)
3. It has been suggested that process substitution could be used instead of a named FIFO:
$ age -d -i <(age -d key.prv) -o msg msg.sec
but this fails for me both on my Mac with bash or zsh, and on a Debian Stretch system with bash. On the Mac, with either shell, I get prompted for the passphrase, but it does not actually get read. If I kill the "age -d key.prv", the shell tries to execute my passphrase as a command. On the Debian system as soon as age prompts for the passphrase it them says "Error: could not read passphrase: could not read passphrase: input/output error" and exits.
4. On the Mac, use the clipboard.
$ age -d key.prv | pbcopy
$ age -d -i <(pbpaste) msg.sec; pbcopy < /dev/null
(If you want the plaintext of the message on the clipboard, you could try this for the second line:
$ age -d -i <(pbpaste) msg.sec | pbcopy
That works most of the time, but occasionally I see it fail saying that there is a malformed key on /dev/fd/<some_number>).
Note that this does show that there is no inherent problem with using process substitution to provide the key "file" to age for decryption. The problem in #3 seems to be when age is used for the command within the substitution and it has to prompt for a passphrase.
6. Similar awkwardness arises if rather than storing you private key in an age passphrase encrypted file you store it in a password manager, such as in a 1Password secure note. If you copy the private key, you need to find a way to paste it to age.
Process substitution works:
$ age -i <(echo AGE-SECRET-KEY-18CP0EEC6QAZ09FG9R423JMMWRFSGVR32ANET54EHQ7ZHW690DVKSR07ZHQ) -d msg.sec
You might not want the key echoed on the terminal. This would work to avoid that:
$ mkfifo f
$ SAVE=$(stty -g)
$ age -d -i f msg.sec &
$ stty -echo
$ cat > f
(paste the private key, hit return, hit ctrl-d)
$ stty $SAVE
$ rm f
It would be a lot less awkward if -i simply accepted encrypted key files.
Now suppose we receive a file, msg.sec, that was encrypted using our public key. If our key file were not encrypted, we could decrypt the message as so:
With the private key encrypted, we need to decrypt it into a file, use the file with the above command, and then presumably get rid of the decrypted private key file. There are a few ways to do this on Unix and Unix-like systems.1. Use an actual file.
I dislike this. What if something like Time Machine happens to take a snapshot right as I'm doing this, and key.tmp gets into the backup?2. Use a named FIFO.
3. It has been suggested that process substitution could be used instead of a named FIFO: but this fails for me both on my Mac with bash or zsh, and on a Debian Stretch system with bash. On the Mac, with either shell, I get prompted for the passphrase, but it does not actually get read. If I kill the "age -d key.prv", the shell tries to execute my passphrase as a command. On the Debian system as soon as age prompts for the passphrase it them says "Error: could not read passphrase: could not read passphrase: input/output error" and exits.4. On the Mac, use the clipboard.
(If you want the plaintext of the message on the clipboard, you could try this for the second line: That works most of the time, but occasionally I see it fail saying that there is a malformed key on /dev/fd/<some_number>).Note that this does show that there is no inherent problem with using process substitution to provide the key "file" to age for decryption. The problem in #3 seems to be when age is used for the command within the substitution and it has to prompt for a passphrase.
6. Similar awkwardness arises if rather than storing you private key in an age passphrase encrypted file you store it in a password manager, such as in a 1Password secure note. If you copy the private key, you need to find a way to paste it to age.
Process substitution works:
You might not want the key echoed on the terminal. This would work to avoid that: It would be a lot less awkward if -i simply accepted encrypted key files.