☰

Como o GPG determina internamente com quais chaves tentar descriptografar um determinado blob de criptografia de entrada?

tag-icon • tag-icon gnupg pgp gpg4win
Como o GPG determina internamente com quais chaves tentar descriptografar um determinado blob de criptografia de entrada?

Tenho lutado com o GPG ultimamente e acabei (finalmente!) de fazê-lo funcionar. Agora posso inserir um blob criptografado em gpg.exe e ele exibirá a versão em texto simples, assumindo que seja um blob de criptografia válido, é claro, o que significa que sua chave de descriptografia está na minha lista de chaves privadas/"identificações criptográficas".

Minha pergunta é: como exatamente o GPG determina qual dessas chaves tentar? Essas informações estão de alguma forma inseridas no blob de criptografia? Ou apenas os testa cegamente, um por um, até que alguém os descriptografe com sucesso?

Seria bom finalmente obter uma resposta para essa pergunta, porque estou pensando sobre isso há muito tempo. Parece tão "bruto" e "de baixa tecnologia" simplesmente passar por todos eles assim. Principalmente se, por exemplo, eu começar a hospedar algum tipo de serviço onde as chaves privadas de milhares de pessoas tenham que passar para ver se uma nova mensagem recebida corresponde a alguma delas. Simplesmente não parece "escalar".

Espero que haja algo no texto criptografado que indique ao GPG qual chave tentar! É esse o caso?

Responder1

O pacote OpenPGP resultante contém de fato oID da subchave de criptografiado destinatário que deveria ser capaz de descriptografá-lo. Por exemplo:

$ date | gpg --encrypt | pgpdump
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xCE7B0F19551034EF
    Pub alg - RSA Encrypt or Sign(pub 1)
    ...
New: Symmetrically Encrypted and MDC Packet(tag 18)(83 bytes)
    ...

Se houver vários destinatários, haverá vários pacotes de “Chave de Sessão” – um para cada destinatário, todos contendo versões criptografadas de forma diferente da mesma chave simétrica.

(Acho que a próxima versão da especificação, v5, está planejando ter impressões digitais completas de subchaves. No entanto, nesta situação, os IDs de chave truncados são bons o suficiente.)

Dito isto, o GnuPG tem uma opção chamada --throw-keyids, que faz com que todos os pacotes de chaves de sessão tenham o mesmo ID de chave 0x0000000000000000. Quando isso acontece, o destinatário realmente tenta descriptografar o pacote por força bruta, usando todas as subchaves secretas com capacidade de criptografia que possui.

Há também uma --hidden-recipientopção que permite ocultar destinatários individuais da mesma maneira, para que você possa ter uma combinação de IDs de chave nulos e não nulos na mensagem resultante. Isso pode ser útil para implementar Bcc:cópias carbono em clientes de e-mail.

Ambas as opções podem ser usadas quando você precisa trocar mensagens por meio de algo como um quadro de avisos/caixa suspensa/subreddit público e não deseja revelar o destinatário pretendido.

$ date | gpg -e --recipient Alice --hidden-recipient Robert | gpg --list-packets
gpg: anonymous recipient; trying secret key CE7B0F19551034EF ...
gpg: anonymous recipient; trying secret key DCDBB36BD91759A3 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with 4096-bit RSA key, ID CE7B0F19551034EF, created 2009-10-31
gpg: encrypted with RSA key, ID 0000000000000000
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 0000000000000000
    data: [4095 bits]
# off=527 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid CE7B0F19551034EF
    data: [4092 bits]
# off=1054 ctb=d2 tag=18 hlen=2 plen=80 new-ctb
:encrypted data packet:
...

informação relacionada