Mise à jour
Alors que le post original ci-dessous explique correctement pourquoi vous pourriez vouloir utiliser des clés d'encryption et de signature distinctes, il ne répond pas très bien à la question de pourquoi vous utilisez des sous-clés au lieu de la clé principale. Le Wiki Debian fournit une réponse beaucoup plus complète.
En résumé, votre clé principale est votre identité en ligne, et votre identité et réputation sont construites en ayant d'autres personnes affirmant que la clé vous appartient en la signant eux-mêmes. (Vous pourriez penser à cela comme étant votre nom d'utilisateur Twitter, et votre réputation étant vos followers sur Twitter, ou vous pourriez contester cette analogie, mais j'espère qu'elle vous donne une idée de pourquoi vous voulez la protéger.) Donc, puisque votre clé principale est très importante et se construit au fil des ans, vous voulez la protéger énormément. En particulier, vous ne voulez pas la stocker sur un ordinateur qui pourrait être volé ou piraté; vous voulez garder votre clé principale hors ligne dans un endroit sûr.
Cela rend bien sûr votre clé principale très inconvenante à utiliser. Donc, pour les opérations quotidiennes, vous voulez utiliser une clé qui ne pose pas autant de problèmes à remplacer si elle est compromise. C'est pourquoi les sous-clés ont été inventées.
Une sous-clé est toujours une paire de clés publique/privée et est sécurisée tant que vous êtes le seul à avoir la clé privée. Cryptographiquement, elle est aussi sécurisée que votre clé principale. La différence est que votre réputation n'y est attachée que par votre propre signature, la signature de votre clé privée. Pour utiliser l'analogie Twitter, le monde fait confiance à ce que vous êtes votre nom d'utilisateur Twitter car tous vos followers le disent (je sais, ça ne fonctionne pas toujours vraiment comme ça, mais les analogies sont difficiles!), puis avec cette confiance établie, vous pouvez bien plus facilement convaincre le monde que vous possédez votre nom d'utilisateur Instagram en tweetant simplement et les gens vous croiront car le tweet vient de votre compte, en qui ils ont confiance.
Vous voulez toujours garder votre sous-clé en sécurité, mais maintenant si elle est compromise, ce n'est pas le gros problème que ce serait si votre clé principale était compromise (ou, dans l'analogie, si quelqu'un piratait votre compte Twitter). Maintenant, vous pouvez simplement révoquer la sous-clé et émettre une nouvelle en signant un certificat de révocation et une nouvelle sous-clé et en les postant tous les deux sur votre trousseau de clés publique (comme tweetant "hé, mon nom d'utilisateur Instagram a changé, n'utilisez pas l'ancien, utilisez celui-ci à la place"). Cela rend le fait de garder votre sous-clé sur votre ordinateur portable un risque plus acceptable que de garder votre clé principale dessus.
TL;DR Les sous-clés facilitent beaucoup la gestion des clés en séparant les fonctions cryptographiques des clés publiques de celles de confiance et d'identité des clés publiques (principales).
Post original
Si vous regardez les détails des mathématiques de l'encryption à clé publique, vous découvrirez que signer et décrypter sont en fait des opérations identiques. Ainsi, dans une implémentation naïve, il est possible de piéger quelqu'un pour qu'il décrypte un message en lui demandant de le signer.
Plusieurs choses sont faites en pratique pour se protéger contre cela. La plus évidente est que vous ne signez jamais un message réel, vous signez plutôt un hash sécurisé du message. Moins évidemment, mais juste pour être plus sûr, vous utilisez des clés différentes pour signer et encrypter. De plus, garder la clé d'encryption séparée vous permet de garder les autres clés, arguablement plus importantes et certainement moins utilisées, hors ligne et plus sécurisées. C'est le cas des clés que vous avez inspectées. Au fait les drapeaux signifient :
- e = encrypter/décrypter (décrypter un message que vous avez reçu encrypté pour que vous puissiez le lire)
- s = signer (signer des données. Par exemple un fichier ou envoyer un e-mail signé)
- c = certifier (signer une autre clé, établissant une relation de confiance)
- a = authentifier (se connecter à SSH avec une clé PGP; cette utilisation est relativement nouvelle)
Notez que dans tous les cas, "clé", signifie une paire de clés publique & privée.
Cela ne devrait pas poser de problème pour votre ami s'il a tout configuré correctement, mais configurer tout correctement peut être plus complexe que cela ne le devrait. Donc la meilleure solution pourrait être pour votre ami de générer une nouvelle clé publique qu'il utilise à la fois pour signer et encrypter. Comme je l'ai dit, parce que la principale défense contre une attaque est de signer uniquement un hash cryptographiquement sécurisé d'un message, ce n'est pas une faiblesse sérieuse d'avoir une telle clé.
