Ok ok, so I'm probably missing something super obvious, but here is my scenario.
Few months back, I decided "Hey, I should probably start keeping paper copies of sensitive data in case all my hard drives crash." The first I decided was small but significant enough to back up was my PGP key, especially considering I had already uploaded it to a SKS pool.
So after arduous research, I established that OCR software isn't the way to go (simply too many chances for it to fail), and focused my sights on QR codes. Sadly, I quickly learned that the maximum byte capacity for an alphanumeric QR code was 4296, whereas my private PGP key is about 6.7KB large armored. Even removing the ASCII armoring, it was still about 4.9KB large. Just out of reach.
Well I was talking to a friend of mine earlier, telling him the story of how I had to split the key onto 3 different pages of massive QR codes, and he looked at me weirdly, then explained the PaperKey software. Perfect!
So I did a little more reading and thought that it was the perfect solution! Well uh. Yeah, it's supposed to be, and apparently it is for most... But upon extracting the private key from my GPG keyring (a 4096-bit RSA/RSA PGP key with a separate subkey for encryption), I was ran it through paperkey, aaaaand the output was 11 kilobytes large...
The format of the output was as such
# Secret portions of key [key-id] # Base16 data extracted Mon Oct 31 20:08:43 2016 # Created with paperkey 1.3 by David Shaw # # File format: # a) 1 octet: Version of the paperkey format (currently 0). # b) 1 octet: OpenPGP key or subkey version (currently 4) # c) n octets: Key fingerprint (20 octets for a version 4 key or subkey) # d) 2 octets: 16-bit big endian length of the following secret data # e) n octets: Secret data: a partial OpenPGP secret key or subkey packet as # specified in RFC 4880, starting with the string-to-key usage # octet and continuing until the end of the packet. # Repeat fields b through e as needed to cover all subkeys. # # To recover a secret key without using the paperkey program, use the # key fingerprint to match an existing public key packet with the # corresponding secret data from the paper key. Next, append this secret # data to the public key packet. Finally, switch the public key packet tag # from 6 to 5 (14 to 7 for subkeys). This will recreate the original secret # key or secret subkey packet. Repeat as needed for all public key or subkey # packets in the public key. All other packets (user IDs, signatures, etc.) # may simply be copied from the public key. # # Each base16 line ends with a CRC-24 of that line. # The entire block of data ends with a CRC-24 of the entire block of data. [hexadecimal output]
I'm quite impressed that a piece of software designed to extract the bare-minimum of a key managed to bloat the output to nearly 2x the size of what is already considered "large". Or is this a PICNIC scenario?
Even leaving out the commented-out header, and only keeping the hex values for the private key data, that was still 9.4KB, waaaay too large to effectively put into a paper copy.
So what, is my key simply too large? Does PaperKey not support subkeys? What other alternatives do I have? Or am I stupid and somebody is going to respond in a single line that says "You forgot to add this parameter"? Or am I stuck with my 3 pieces of paper covered in QR codes?