Paperkey-Ausgabedatei deutlich größer als der ursprüngliche geheime Schlüssel

Ok, ich vermisse wahrscheinlich etwas Super offensichtliches, aber hier ist mein Szenario.

Vor ein paar Monaten entschied ich mich "Hey, ich sollte wahrscheinlich anfangen, Papierkopien sensibler Daten aufzubewahren, falls alle meine Festplatten abstürzen." Der erste, für den ich mich entschieden hatte, war klein, aber bedeutsam genug, um meinen PGP-Schlüssel zu sichern. Vor allem, da ich ihn bereits in einen SKS-Pool hochgeladen hatte.

Nach langwieriger Recherche stellte ich fest, dass OCR-Software nicht der richtige Weg ist (einfach zu viele Chancen für ein Scheitern) und konzentrierte mich auf QR-Codes. Leider erfuhr ich schnell, dass die maximale Bytekapazität für einen alphanumerischen QR-Code 4296 betrug, während mein privater PGP-Schlüssel etwa 6,7 ​​KB groß ist. Selbst wenn die ASCII-Armierung entfernt wurde, war sie immer noch etwa 4,9 KB groß. Nur außerhalb der Reichweite.

Ich habe vorhin mit einem Freund von mir gesprochen und ihm erzählt, wie ich den Schlüssel auf drei verschiedene Seiten QR-Codes aufteilen musste. Er sah mich komisch an und erklärte dann die PaperKey-Software. Perfekt!

Also las ich ein bisschen mehr und dachte, es wäre die perfekte Lösung! Na ja. Ja, das sollte es sein, und anscheinend ist es für die meisten ... Aber als ich den privaten Schlüssel aus meinem GPG-Schlüsselbund (einen 4096-Bit-RSA / RSA-PGP-Schlüssel mit einem separaten Unterschlüssel für die Verschlüsselung) extrahierte, wurde ich durch Papierspeicher geführt, aaaaund die Ausgabe war 11 Kilobytes groß ...

Das Format der Ausgabe war so

# 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] 

Ich bin ziemlich beeindruckt, dass eine Software, mit der das absolute Minimum eines Schlüssels ermittelt werden konnte, die Ausgabe auf fast das Doppelte der bereits als "groß" betrachteten Größe aufblähen konnte. Oder ist das ein PICNIC-Szenario?

Selbst wenn der auskommentierte Header ausgelassen wurde und nur die Hex-Werte für die privaten Schlüsseldaten beibehalten wurden (9,4 KB), war er zu groß, um sie effektiv in Papierform zu kopieren.

Was ist mein Schlüssel einfach zu groß? Unterstützt PaperKey keine Unterschlüssel? Welche anderen Alternativen habe ich? Oder bin ich dumm und jemand wird in einer einzigen Zeile antworten, in der steht "Sie haben vergessen, diesen Parameter hinzuzufügen"? Oder bleibe ich bei meinen 3 in QR-Codes abgedeckten Papieren?