web-dev-qa-db-fra.com

Clé principale et sous-clé GPG pour le chiffrement et la signature et clés par défaut

Je suis un peu confus (comme beaucoup d'autres) sur le concept de sous-clés lié à la clé primaire. gpg par défaut (au moins, il semble sur mon système --- en utilisant RSA), sur gpg --gen-key crée un masterkey et un subkey. Le masterkey a des drapeaux SC qu'il pourrait être utilisé pour la signature et la certification. Il crée également une sous-clé avec l'indicateur E, utilisée pour le chiffrement. Les affirmations suivantes sont-elles correctes?

  • Si je comprends tout le concept, le masterkey et le subkey sont des paires de clés, c'est une paire de clés privées-publiques.
  • le fait que l'on ne soit que pour le cryptage est dû au fait que certains algorithmes ont une telle exigence (nécessitent des clés distinctes pour le cryptage et la signature)
  • L'indicateur subkey avec E: sa partie publique peut être utilisée pour crypter des informations et sa partie privée pour décrypter les informations qui ont été cryptées avec la partie publique.
  • Le drapeau masterkey avec SC: sa partie privée est utilisée pour signer/certifier et sa partie publique est utilisée pour vérifier la validité de la signature.

La partie la plus déroutante est quand je suis le conseil de créer plus de subkeys, un pour la signature, un pour le cryptage. Appelons simplement le cryptage d'origine subkeyESK0 et le nouveau cryptage subkeyESK1, et la nouvelle signature subkeySSK1 et le masterkeyMK.

Après avoir créé ESK1 et SSK1 Je devrais avoir au total 4 paires de clés publiques/privées, correct? Ensuite, en suivant les guides, je supprime le MK sur un support hors ligne et le supprime de mon ordinateur, donc j'ai maintenant dans mon ordinateur:

  • Un couple public/privé ESK0 (cryptage d'origine)
  • Un couple public/privé ESK1 (nouveau cryptage)
  • Un couple public/privé SSK1 (nouvelle signature)
  • Une clé publique pour MK

Je change ensuite de mot de passe en utilisant gpg --edit-key $id passwd. Selon certains guides, il devrait changer le mot de passe pour les sous-clés, mais je n'en suis pas si sûr, je pense que cela change simplement le mot de passe pour toute la structure délimitée par MK c'est juste que la structure avec private MK stocké hors ligne a toujours l'ancien mot de passe. Qui est correct?

Maintenant, si je signe quelque chose, quelle est la clé de signature? Je crois que ça doit être SSK1 puisque MK n'est plus disponible. Correct?

Je télécharge ensuite une clé publique sur un serveur de clés à l'aide de gpg --send-key $id. Quelles clés publiques ai-je téléchargées?

Si quelqu'un utilise les informations du serveur de clés pour m'envoyer des informations chiffrées, quelle clé publique sera utilisée pour le chiffrement - ESK0 ou ESK1? Je crains que ce ne soit ESK0 depuis lors, l'intérêt d'avoir des sous-clés serait complètement inutile car pour le décryptage j'utiliserais toujours ESK0.

Aussi, pourquoi les guides suggèrent-ils la suppression de MK mais le ESK0 est toujours censé rester sur le système? Quel est le but de ESK1 puis?

Merci pour toute aide.

9
leosenko

Si vous avez déjà une clé SC et E et que vous souhaitez supprimer votre clé C ("maître") du stockage hors ligne, alors tout ce dont vous avez besoin est une nouvelle clé S (SSK1 dans votre exemple) Vous n'avez pas besoin de créer une nouvelle sous-clé de chiffrement - votre clé existante est très bien à cet effet.

Je change ensuite de mot de passe en utilisant gpg --edit-key $id passwd. Selon certains guides, il devrait changer le mot de passe pour les sous-clés, mais je ne suis pas sûr de cela, je pense que cela change simplement le mot de passe pour toute la structure limitée à MK, c'est juste que la structure avec MK privé stocké hors ligne a toujours le ancien mot de passe. Qui est correct?

Vous allez modifier la phrase secrète sur toutes les sous-clés stockées localement, c'est donc une chose parfaitement valide à faire. La phrase secrète de la clé principale hors ligne ne changera pas. La phrase secrète est ce que GnuPG utilise pour crypter symétriquement vos clés privées avant de les stocker sur le disque (pour vous assurer qu'elles ne sont pas facilement volées via des logiciels malveillants ou des sauvegardes mal sécurisées).

Maintenant, si je signe quelque chose, quelle est la clé de signature? Je pense que ce doit être SSK1 car MK n'est plus disponible. Correct?

Par défaut, GnuPG utilise la dernière clé S créée, donc SSK1 sera toujours utilisé dans votre cas - c'est ce que vous voulez.

Je télécharge ensuite une clé publique sur un serveur de clés à l'aide de gpg --send-key $ id. Quelles clés publiques ai-je téléchargées?

Vous téléchargez toutes les données de clé publique, y compris les nouvelles sous-clés ou identités.

Si quelqu'un utilise les informations du serveur de clés pour m'envoyer des informations chiffrées, quelle clé publique sera utilisée pour le chiffrement - ESK0 ou ESK1? Je crains que ce ne soit ESK0 car alors l'intérêt d'avoir des sous-clés serait complètement inutile car pour le décryptage, j'utiliserais toujours ESK0.

Avoir plusieurs sous-clés de chiffrement valides est une recette pour quelque chose comme ça, donc je vous recommande fortement de ne PAS créer une nouvelle sous-clé de chiffrement. Comme je l'ai dit, vous n'avez pas besoin d'une nouvelle sous-clé de chiffrement si vous en avez déjà une.

Aussi, pourquoi les guides suggèrent-ils la suppression de MK mais l'ESK0 est toujours censé rester sur le système? Quel est le but d'ESK1 alors?

La "clé principale" est votre clé "C" (certifier). C'est la clé utilisée pour signer les clés des autres et vos propres sous-clés et identités. Si l'une de vos sous-clés E ou S est perdue ou si vous craignez qu'elles soient exposées à des logiciels malveillants, vous pouvez simplement les révoquer et en créer de nouvelles tant que vous faites confiance à l'intégrité de votre clé C. C'est pourquoi il est recommandé que votre clé C ("clé principale") soit soigneusement sauvegardée et stockée hors ligne.

À la fin, votre objectif est d'avoir la structure suivante:

  • clé [SC] existante - stockée hors ligne, supprimée du disque local
  • clé [E] existante - conservée sur le disque
  • nouvelle clé [S] - conservée sur le disque

Remarque finale - par défaut, GnuPG crée votre clé principale en tant que [SC], mais ce n'est pas obligatoire. Vous pouvez spécifiquement dire à GnuPG de créer une clé [C] autonome.

8
mricon