README: add detailed paperkey instructions

[matheusmoreira]

Document the paperkey backup and restoration process. Includes instructions on backing up to printed QR codes.

[drduh]

Looks good. Let's move this to Optional hardening, since I do not believe most people will want or need to do these steps. What do you think?

[jeevsobs]

The instructions as-is don't seem to be compatible with the guide. There are several problems I encountered:

First of all, the guide's gpg.conf specifies that exports be armored by default but paperkey accepts binary inputs.

To solve this is simple, just export the gpg dearmored when piping into paperkey.
(e.g. gpg --batch --pinentry-mode=loopback --passphrase "$CERTIFY_PASS" --export-secret-keys $KEYID | gpg --dearmor | paperkey | lpr)

You can then simply print out the human-readable paperkey. That's fine if that's all you want but it's inconvenient for recovery since the recovery input sequence is extremely long.

This is where another problem that arises if you want to use QR codes for practicality. qrencode will throw an error saying the input is too large. This is due to the paperkey being over the maximum 3KB limit of QR data. Even if you could somehow fit it in, the QR code is difficult to scan, especially if your scanning hardware isn't great (e.g. bad webcam).

A solution to this would be to split the paperkey into multiple files and encode those separately. Recovery would involve decoding the QR codes and concatenating the files together for import.
A way to approach this process is described here: https://maxammann.org/posts/2021/01/keeping-secret-safe/

Just thought that I would bring these issues up before anything is merged. I can provide advice for rewriting this section if needed.

[matheusmoreira]

First of all, the guide's gpg.conf specifies that exports be armored by default but paperkey accepts binary inputs.

That's true. Paperkey does require binary input and gpg outputs binary OpenPGP packets by default. I didn't notice that this default had been reconfigured. Will fix.

You can then simply print out the human-readable paperkey.

You can and you absolutely should. If the QR code is dense enough, you can run into serious trouble trying to read it back in. 4096 bit RSA keys are particularly problematic, they produce very dense QR codes even with the lowest possible error correction setting.

I would have lost an encryption key if I hadn't printed out the paperkey pages. Restoring a 4096 bit RSA key that way was nightmarish but it worked.

That's fine if that's all you want but it's inconvenient for recovery since the recovery input sequence is extremely long.

Yeah. I bought two YubiKey 5s with Curve25519 support after that taxing experience. The keys are much smaller, you can actually read the QR code back in.

qrencode will throw an error saying the input is too large.

Even 4096 bit RSA keys will fit into QR codes. You just need to use binary mode and paperkey's raw output mode to pipe just the key itself into qrencode. Don't pipe the base16 output into qrencode.

the QR code is difficult to scan, especially if your scanning hardware isn't great (e.g. bad webcam).

This is true. I should probably add that warning to the guide too.

A solution to this would be to split the paperkey into multiple files and encode those separately.

QR codes actually have native support for this, they call it structured append. Many other types of barcodes support this as well. QR codes support appending up to 16 symbols. I've yet to come across reader apps that supports it though.

[jeevsobs]

Might want to point out that you used ed25519 keys then. Were you able to get the guide's keys working? I wasn't able to pipe the guide's rsa4096 key with the 3 subkeys into qrencode. I did indeed use paperkey raw output and a rsa4096 without subkeys worked.

I do agree that you should definitely print out the text paperkey. Always good to have more backups. Also, Interesting tidbit about structured append.

[matheusmoreira]

@jeevsobs

I wasn't able to pipe the guide's rsa4096 key with the 3 subkeys into qrencode.

I do see the problem! There's indeed a mistake in my pull request.

gpg has a rather unfortunate interface. When you --export-secret-keys it won't export just the key you asked for, it'll export the entire keyring. This happens even if you specify the key by ID or fingerprint.

In order to make it export only the desired key, it needs an exclamation mark ! appended to the ID or fingerprint.

gpg --export-secret-key "${KEYID}"'!' | paperkey | lpr
gpg --export-secret-key "${KEYID}"'!' | \ 
     paperkey --output-type raw | \ 
     qrencode --8bit --output
     "${KEYID}".secret-key.qr.png

An entire key ring is probably too big for a QR code, especially 4096 bit RSA keys, but without the ! I'm not sure even the ECC keys will fit.

Thanks for testing it and catching this issue!!!

[drduh]

@matheusmoreira do you have additional changes for this PR? Thank you.

[koddo]

To me it's ok to split the huge resulting binary paperkey of rsa4096 into multiple pieces.

[drduh]

Additional testing and feedback is needed here with large (RSA 4096) keys to continue. I will give these instructions a try on my next key iteration.