Выходной файл Paperkey значительно больше исходного секретного ключа

Хорошо, хорошо, так что я, вероятно, упускаю что-то супер очевидное, но вот мой сценарий.

Несколько месяцев назад я решил: «Эй, мне лучше начать хранить бумажные копии конфиденциальных данных на случай, если все мои жесткие диски выйдут из строя». Сначала я решил, что он небольшой, но достаточно значительный для резервного копирования, - это мой ключ PGP, особенно с учетом того, что я уже загрузил его в пул SKS.

Поэтому, после трудных исследований, я установил, что программное обеспечение для оптического распознавания символов не является подходящим способом (просто слишком много шансов на провал), и сосредоточил свое внимание на QR-кодах. К сожалению, я быстро узнал, что максимальная емкость байта для буквенно-цифрового QR-кода составляет 4296, тогда как мой личный ключ PGP имеет большой размер брони около 6,7 КБ. Даже при удалении брони ASCII, она все еще была размером около 4,9 КБ. Просто вне досягаемости.

Ну, я разговаривал с моим другом ранее, рассказывая ему историю о том, как мне пришлось разделить ключ на 3 разные страницы массивных QR-кодов, и он странно посмотрел на меня, затем объяснил программное обеспечение PaperKey. Отлично!

Поэтому я немного почитал и подумал, что это идеальное решение! Ну, эээ Да, так и должно быть, и, видимо, для большинства ... Но после извлечения секретного ключа из моего набора ключей GPG (4096-битный RSA / RSA-ключ PGP с отдельным подключом для шифрования) я проверил его через paperkey ааааа а вывод был 11 килобайт большой ...

Формат вывода был таким

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

Я весьма впечатлен тем, что программному обеспечению, предназначенному для извлечения минимума ключа, удалось раздуть вывод почти в 2 раза по сравнению с размером, который уже считается «большим». Или это сценарий ПИКНИКА?

Даже оставляя закомментированный заголовок и сохраняя только шестнадцатеричные значения для данных закрытого ключа, которые все еще были 9,4 КБ, они слишком велики, чтобы их можно было поместить в бумажную копию.

Так что, мой ключ просто слишком большой? PaperKey не поддерживает подключи? Какие у меня есть альтернативы? Или я тупой, и кто-то ответит одной строкой: «Вы забыли добавить этот параметр»? Или я застрял с 3 листами бумаги, покрытыми QR-кодами?