☰

Ainda confuso sobre chaves e subchaves GPG

tag-icon • tag-icon command-line encryption gnupg
Ainda confuso sobre chaves e subchaves GPG

Acabei de gerar uma nova chave com

gpg --quick-generate-key

Agora, quando eu faço

gpg --list-keys[e-mail protegido]

Eu recebo algo assim:

pub   rsa2048 2020-01-29 [SC] [expires: 2022-01-28]
      DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF
uid           [ultimate] [email protected]
sub   rsa2048 2020-01-29 [E]

mas quando eu faço isso:

gpg --edit-key[e-mail protegido]

Eu recebo algo como o seguinte:

gpg (GnuPG) 2.2.17; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa2048/DEADBEEFDEADBEEF
     created: 2020-01-29  expires: 2022-01-28  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/BEEFDEADBEEFDEAD
     created: 2020-01-29  expires: never       usage: E   
[ultimate] (1). [email protected]

Achei que entendia pelo menos um pouco o conceito de chaves e subchaves, mas isso ainda não faz sentido para mim.

  1. Por que a saída mostra chaves públicas em um caso e chaves secretas no outro?
  2. Como é que uma chave pública ( pub) é mostrada como capaz de assinar ( S) no primeiro caso, e uma chave secreta ( ssb) é mostrada como capaz de criptografar ( E) no segundo caso? Isso não vai contra o que aprendemos em Public Key Crypto 101?

Responder1

Por que a saída mostra chaves públicas em um caso e chaves secretas no outro?

No GnuPG 2.1+, eu acho que o --edit-keycomando mostra chaves secretas porque é isso que sempre fez.

De volta ao GnuPG 1.x (e de forma semelhante ao PGP 2.x original), havia dois chaveiros totalmente separados (pubring e secreing). Algumas operações funcionaram com uma e outras funcionaram com a outra. Costumava --list-secret-keysser exatamente igual, --list-keysexceto que lia de um arquivo diferente e --edit-keystinha um subcomando que alternava entre as duas visualizações.

Como é que uma chave pública (pub) é mostrada como capaz de assinar (S) no primeiro caso, e uma chave secreta (ssb) é mostrada como capaz de criptografar (E) no segundo caso? Isso não vai contra o que aprendemos em Public Key Crypto 101?

Não. A saída descreve uma 'chave' como no objeto PGP - não uma 'chave' no sentido criptográfico puro - e os sinalizadores de uso descrevem quais operações PGP sãosignificoupara ser usada, não apenas para quais operações criptográficas a chave "interna" é matematicamente capaz. Isso significa que eles não mudam dependendo se você está olhando para a metade pública ou privada.

Por exemplo, seu bloco de chaves PGP de exemplo possui dois pares de chaves RSA e ambos podem tecnicamente assinar/verificar, bem como criptografar/descriptografar. Mas o objetivo de ter dois é que você deseja manter seus propósitos separados – ou seja, você não quer que o GnuPG execute criptografia usando uma subchave destinada à assinatura, então os sinalizadores de uso o filtram.

(Não há sinalizador separado para "descriptografar" ou "verificar" porque a mensagem ou assinatura já indica qual chave usar para isso.)

Isso também significa que pode haver vários sinalizadores de uso mapeados para a mesma operação (assinatura ou verificação), mas em contextos diferentes:

  • “S” permite que a chave seja utilizada para assinatura de mensagens e arquivos (e-mail, etc.);
  • "C" permite que a chave seja usada para assinar (certificar) outras chaves/subchaves;
  • "A" permite que a chave seja usada para assinar desafios de autenticação (como em TLS ou SSHv2).

Embora todos os três façam o mesmo tipo de assinatura digital no sentido criptográfico, as próprias chaves são frequentemente separadas por razões políticas. (Por exemplo, a chave de certificação deve ser muito mais fortemente protegida do que a chave de autenticação.)

informação relacionada