Pourquoi GPG / PGP utilise-t-il par défaut différentes clés pour la signature / le cryptage?


22

Si vous créez une nouvelle clé GPG, vous obtiendrez par défaut une paire de clés principales de signature uniquement et une paire de sous-clés de chiffrement uniquement.

pub  2048R/XXXXXXXX  created: 2013-02-09  expires: 2014-02-09  usage: SC  
sec  2048R/XXXXXXXX           2013-02-09 [expires: 2014-02-09]

sub  2048R/ZZZZZZZZ  created: 2013-02-09  expires: 2014-02-09  usage: E
ssb  2048R/ZZZZZZZZ           2013-02-09 [expires: 2014-02-09]  

(Sortie combinée de gpg --list-keyset gpg --list-secret-keys)

Il est également recommandé de ne pas utiliser votre clé principale pour la signature régulière (de courriers / données), mais de créer une autre sous-clé de signature uniquement et de supprimer / sauvegarder votre clé principale dans un emplacement sûr et hors ligne uniquement à utiliser pour la signature de clé. .

Cela est logique, car la plupart des points de terminaison de chiffrement sont des ordinateurs portables / téléphones ou d'autres appareils mobiles toujours en ligne qui mettent vos clés privées en danger de vol ou de perte. Avec une clé principale stockée en toute sécurité, vous pouvez toujours révoquer ces sous-clés perdues et ne jamais perdre vos signatures de clé.

Ainsi, bien que la séparation de la sous-clé de la clé principale <-> soit claire pour moi, je ne comprends pas pourquoi l'accent est mis sur la séparation des clés de signature et de cryptage (même s'il s'agit de deux sous-clés). Quelqu'un peut-il expliquer pourquoi cela est nécessaire ou du moins quel est l'avantage d'un point de vue sécuritaire ou pratique?

Techniquement, il est entièrement possible et pris en charge par GnuPG de créer une sous-clé de signature ET de chiffrement.

pub  2048R/YYYYYYYY  created: 2013-08-13  expires: 2014-08-13  usage: SCEA
sub  2048R/VVVVVVVV  created: 2013-08-13  expires: 2014-08-13  usage: SEA 

2
Il y a une bonne réponse à cette question chez Security.SE au cas où quelqu'un serait intéressé.
GnP

Réponses:


9

Au Royaume-Uni, la Regulation of Investigatory Powers Act 2000 dit

49 (9) L'avis prévu au présent article ne doit pas exiger la divulgation d'une clé qui—

(a) est destiné à être utilisé uniquement dans le but de générer des signatures électroniques; et

b) n'a en fait pas été utilisé à d'autres fins.

… Ce qui signifie que le gouvernement britannique peut, dans certaines circonstances, être en mesure de vous obliger à remettre votre clé de déchiffrement (si vous êtes un résident), mais il n'est pas autorisé à vous faire passer pour votre clé de signature.


1
Intéressant ... cela s'appliquerait également aux clés privées Bitcoin (uniquement utilisé pour la signature, pas pour le cryptage).
Jonathan Cross

… Et il semble que cette exemption reste en place dans la loi de 2016 .

8

Je ne sais pas précisément pourquoi GPG / PGP fait ce qu'il fait, mais une des motivations possibles pour ce genre de chose est la reprise après sinistre. Vous voudrez peut-être donner une copie de votre clé privée de chiffrement à un ami de confiance très proche, donc, si votre maison est touchée par une météorite, vous pouvez toujours lire vos anciens messages qui sont enregistrés dans le cloud. (De même, vous devrez peut-être donner votre clé de chiffrement 1 à votre patron, afin qu'il puisse lire votre e-mail après votre départ.)

Mais il n'y a aucune raison pour que quelqu'un d'autre ait une copie de votre paire de clés de signature.
________________
1  «on pourrait vous demander de donner votre clé de chiffrement» à quelqu'un - voir la réponse de TEV .


2

La réponse simple est que plus vous utilisez une clé, plus vous divulguez d'informations sur la clé.

Une clé de signature est utilisée par vous pour authentifier que vous faites confiance à une clé, et par déduction du propriétaire, mais plus important encore, que vos communications proviennent de vous. C'est ce qu'on appelle la non-répudiation .

Par souci d'argument, disons que l'utilisation d'une clé 10000 fois signifie que vous divulguez toutes les informations nécessaires à quelqu'un pour reconstruire cette clé. Utiliser une clé> 9999 fois signifierait que quelqu'un d'autre pourrait potentiellement vous imiter et transmettre votre signature de confiance à la clé ou au document d'un tiers malveillant, ce qui ferait croire à tout votre réseau de confiance que cette partie est vous ou que le document vient de vous.

Cependant, si vous chiffrez également avec cette même clé, le seuil est plus rapidement atteint.

Pour éviter ce désagrément potentiel, une deuxième clé est créée, qui n'est utilisée que pour le cryptage / décryptage, qui n'est utilisée que pour crypter les données comme vous. Une fois que cette clé a été utilisée 9999 fois, vous pouvez expirer cette clé sans perdre toute la confiance que vous avez accordée avec votre clé de signature valide. Vous recréez, générez une nouvelle clé de chiffrement et signez-la avec votre clé de signature pour montrer qu'il s'agit d'une clé de chiffrement approuvée que tout le monde peut vérifier.

MODIFIER:

En relisant ce que j'ai écrit ci-dessus et le GNU Privacy Handbook , ma conclusion est que subc'est une clé privée et pubdoit être une clé publique. @GnP cette réponse:

" The keyword pub identifies the public master signing key, and the keyword sub identifies a public subordinate key."


Je suppose que pour la plupart des gens, la clé de signature est utilisée beaucoup plus souvent que la clé de chiffrement, car presque tous les courriers seront signés mais seulement certains seront chiffrés. Dans ce cas, le gpg-default est dans le mauvais sens, comme l'encr. la clé est facile à changer tandis que la clé de signature ne l'est pas.
Chaos_99

Comme vous cryptez généralement avec la clé publique de quelqu'un d'autre, cela semble quelque peu logique, et il y a probablement de bonnes raisons à cela que je ne connais pas actuellement.
Daniël W. Crompton

Vous avez raison. Veuillez échanger "cryptage" avec "décryptage" dans mon commentaire. Mais le point reste valable. Vous signez plus souvent que vous déchiffrez. J'ai posé cette question pour connaître exactement les "bonnes raisons probablement" que vous avez mentionnées.
Chaos_99

1
Le maître ainsi que la sous-clé sont des paires de clés valides avec des clés publiques et privées. L'abréviation pour le maître privé est «sec», pour la sous-clé privée «ssb». Les deux peuvent être vus avec gpg --list-secret-keys. Les listes ci-dessus ne montrent que les clés publiques retournées par gpg --list-keys.
Chaos_99

1
"Plus vous utilisez une clé, plus vous divulguez d'informations sur la clé". Avez-vous une source pour cette réclamation?
GnP

0

Si vous créez une nouvelle clé GPG, vous obtiendrez par défaut une paire de clés principales de signature uniquement et une paire de sous-clés de chiffrement uniquement.

Les messages peuvent être:

  • non signé et non chiffré
  • signé et non crypté
  • non signé et chiffré
  • signé et crypté

et il existe des utilisations pour chacun de ces cas, selon ce que vous essayez d'accomplir avec la signature et le chiffrement.

Si en signant, vous établissez une identité / une approbation et en chiffrant vous rendez des messages privés, être capable de crypter mais de ne pas signer vous donne la possibilité d'envoyer un message privé qui n'est pas nécessairement associé à votre identité ou approuvé par vous. Vous voudriez des clés séparées dans ce cas.


2
Corrigez-moi si je me trompe, mais je crois que, lorsque vous cryptez un message, vous utilisez la clé (publique) du destinataire , donc, une fois qu'il quitte vos mains, vous ne pouvez pas le retrouver. Votre clé de cryptage permet à d'autres de vous envoyer des messages cryptés.
Scott

@Scott oui, mais la plupart des gens ont généralement un jeu de clés par défaut afin qu'ils puissent lire tout ce qui se trouve dans leur boîte d'envoi et généralement pour spécifier une signature par défaut. Bien que dans ces cas, l'ID de clé de la clé principale / de certification soit utilisé pour sélectionner la bonne sous-clé.
Ben
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.