Ok ok, então provavelmente estou sentindo falta de algo super óbvio, mas aqui está o meu cenário.
Alguns meses atrás, eu decidi: "Ei, eu provavelmente deveria começar a manter cópias em papel de dados sensíveis, caso todos os meus discos rígidos falhem".
O primeiro que eu decidi foi pequeno, mas significativo o suficiente para fazer backup foi minha chave PGP, especialmente considerando que eu já tinha enviado para um pool SKS.
Portanto, depois de uma pesquisa árdua, estabeleci que o software de OCR não é o caminho a seguir (simplesmente há muitas chances de que ele falhe) e concentrei minhas atenções nos códigos QR. Infelizmente, aprendi rapidamente que a capacidade máxima de byte para um código QR alfanumérico era 4296, enquanto minha chave PGP privada tem cerca de 6,7 KB de blindagem grande. Mesmo removendo a blindagem ASCII, ela ainda tinha cerca de 4,9 KB. Apenas fora de alcance.
Bem, eu estava conversando com um amigo meu mais cedo, contando a história de como eu dividi a chave em 3 páginas diferentes de códigos QR enormes, e ele me olhou estranhamente, depois explicou o software PaperKey. Perfeito!
Então eu fiz um pouco mais de leitura e pensei que era a solução perfeita!
Bem. Sim, é suposto ser, e aparentemente é para a maioria ... Mas ao extrair a chave privada do meu chaveiro GPG (uma chave PGP RSA / RSA de 4096 bits com uma subchave separada para criptografia), eu a corri através de paperkey , aaaa e a saída foi 11 kilobytes large ...
O formato da saída foi como tal
# 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]
Estou muito impressionado que um software desenvolvido para extrair o mínimo de uma chave tenha conseguido inchar a saída para quase 2x o tamanho do que já é considerado "grande".
Ou este é um cenário de PICNIC?
Mesmo deixando de fora o cabeçalho comentado, e mantendo apenas os valores hexadecimais dos dados da chave privada, que ainda eram 9,4 KB, é muito grande para efetivamente colocar em uma cópia em papel.
Então, qual é a minha chave simplesmente grande demais? O PaperKey não suporta subchaves? Quais outras alternativas eu tenho? Ou eu sou estúpido e alguém vai responder em uma única linha que diz "Você esqueceu de adicionar este parâmetro"?
Ou eu estou preso com meus 3 pedaços de papel cobertos com códigos QR?