Do not export secret keys

[ghost]

There are two interlinked problems with the install hook right now:

• It assumes the key is on the root keychain. Maybe $HOME can be tested.
• It exports and reimports secret keys into a keychain without password set and writes it to the initramfs. This is a pretty serious fuckup. The only reason this wouldn't write my keys on unencrypted space is that my keys are generated on-smartcard. GPG Smartcards aren't an "additional factor" needed along the keys, they ARE the secret keys.

[fuhry]

Re: testing $HOME: It's not possible to really figure out which user's home directory should be consulted, as mkinitcpio is normally run as root.

Re: exporting secret keys: in the past, I've observed the following behavior with GPG:

• --export-secret-keys was required to include the "smart card stub". I don't believe this is the case with GnuPG2 - it does a much better job of recognizing smartcards and matching public keys with the appropriate private key on the smart card.
• --export-secret-keys has prompted me for the passphrase when exporting, but the exported key was still encrypted. This doesn't make sense to me either (I should be able to export it in its encrypted form without entering a passphrase).

I'll spend some time this weekend checking this behavior under the GnuPG 2.x release shipping with Arch.

[ghost]

sudo should not unset $HOME, but I'm not too sure.

[fuhry]

You can't assume that everyone is running mkinitcpio under sudo, or that root's home directory has not been changed. The best option is for users to export the GNUPGHOME environment variable in root's shell profile if they want to use a homedir other than /root/.gnupg.

Still need to investigate the secret key behavior, which I'll do now.

Edit: fixed name of the environment variable (it's GNUPGHOME, not GPGHOMEDIR)

[fuhry]

I have confirmed that in the current version of GnuPG, exporting the secret key does prompt you for a passphrase, but the resulting key output remains encrypted with the original passphrase. It is not stored in an unprotected format.

My testing methodology was as follows:

• Create new GPG homedir: export GNUPGHOME=/home/gpgtest/.gnupg-hd1
• Generate a new key: gpg --gen-key
• Enter a strong passphrase to protect it
• Export the key, ascii-armored: gpg -a --export-secret-keys name@email.tld > privkey.asc - result: prompted for password
• Change GPG homedir: export GNUPGHOME=/home/gpgtest/.gnupg-hd2
• Import the key file: gpg --import privkey.asc - result: prompted for password
• Sign a test message: gpg --clearsign -a - result: prompted for password

At all of these stages, I tried entering an incorrect password as well - the operation failed at that point. This proves that the strong password I set was preserved as the secret key passphrase throughout the process of generating, exporting, importing and signing.

To me it's quite silly that GPG is prompting for the passphrase during import and export. These are not crypto operations, and it's quite easy to duplicate someone's secret key by copying the *.key files in $GNUPGHOME/private-keys-v1.d/. It's also confusing because entry of the passphrase implies that you're decrypting the key, even though you're not. Nevertheless, this is the current behavior. According to the man page, this appears to be caused by differences in the key storage format, which necessitates decrypting and re-encrypting the secret key material.

TL;DR: secret keys remain encrypted when exported. One could argue they are considerably easier to bruteforce if collected in isolation as opposed to attacking full disk encryption, however they are still encrypted.

[ghost]

Older versions (notably gpg1) seem to export unencrypted, I had unencrypted output from Arch-packaged gpg around mid 2014 (where I had to actually set a new passphrase on the computer I moved the key to, pipe gpg --symmetric comes in handy there). I guess the password prompt is either a legacy feature left in or for those rare cases you have a GPG agent that's not under your direct control (different user, remote).

A public key export was enough to work for me while testing the hook, though I realize works for isn't quite the bar packages should aspire to.

[fuhry]

While the original intent of this hook is to facilitate smartcard use, I've aimed to keep this hook working for passphrase decryption as well.

Given that:

• Most users will be using OpenPGP smartcards, which does not store the secret key on disk;
• the install script is careful to only export the secret key(s) that are needed to decrypt disks in /etc/crypttab;
• and the secret key needs to be exported anyway in the passphrase use case;

I think it is best to leave --export-secret-keys in there for now.

Thanks for bringing this to my attention - even though the status quo is not changing, the decision has actually been thought through now.

I'll leave this issue open until the GNUPGHOME bit is documented in the readme.