Si le pire est la perte de la Sous-clef de chiffrement, il faudrait la protéger au moins autant que la clef primaire non ?
Je chipote, mais le pire n’est pas la perte : si tu perds ta sous-clef de chiffrement, tu sais que tu dois la considérer comme compromise, tu la révoques et tu en génères une autre. Dans le pire des cas, seules tes communications passées (jusqu’au moment où tu réalises la perte) sont potentiellement compromises.
Le pire, c’est une exfiltration réalisée de telle sorte que tu ne t’aperçois de rien, parce que tes correspondants vont alors continuer à t’envoyer des messages chiffrés avec cette clef, que ton attaquant pourra lire tranquillement. Tes communications passées et futures sont compromises.
Cela étant, oui, la sous-clef de chiffrement est à protéger avec soin, autant sinon plus que la clef primaire. C’est tout l’intérêt de la mettre sur un token comme la carte OpenPGP.
je pars du principe que chiffrer dans un token est trop lent
Ce n’est pas le cas.
D’une part, le token ne chiffre jamais, il ne fait que déchiffrer — le chiffrement ne requiert que la clef publique de ton correspondant, aucune raison de mettre celle-ci sur un token. Mais je chipote encore (désolé), il est évident que tu parlais de déchiffrer.
D’autre part, on ne déchiffre avec la clef privée rien de plus que la clef de session symétrique avec laquelle on peut ensuite déchiffrer le corps du message. La complexité de l’opération RSA fait que déchiffrer la clef de session est déjà, la plupart du temps, la partie la plus lente (même si le corps du message est beaucoup plus gros que la clef de session, AES est beaucoup plus rapide à déchiffrer, d’autant plus que beaucoup de processeurs ont des instructions AES spécifiques), faire effectuer cette opération par un token ne la ralentit pas beaucoup plus.
Ou alors, il faut révoquer périodiquement cette sous clef.
C’est une possibilité en effet. Je n’irai pas jusqu’à le recommander, mais c’est une option à considérer en fonction des opposants auxquels on pense faire face.
[^] # Re: Sous-clef de chiffrement
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Je chipote, mais le pire n’est pas la perte : si tu perds ta sous-clef de chiffrement, tu sais que tu dois la considérer comme compromise, tu la révoques et tu en génères une autre. Dans le pire des cas, seules tes communications passées (jusqu’au moment où tu réalises la perte) sont potentiellement compromises.
Le pire, c’est une exfiltration réalisée de telle sorte que tu ne t’aperçois de rien, parce que tes correspondants vont alors continuer à t’envoyer des messages chiffrés avec cette clef, que ton attaquant pourra lire tranquillement. Tes communications passées et futures sont compromises.
Cela étant, oui, la sous-clef de chiffrement est à protéger avec soin, autant sinon plus que la clef primaire. C’est tout l’intérêt de la mettre sur un token comme la carte OpenPGP.
Ce n’est pas le cas.
D’une part, le token ne chiffre jamais, il ne fait que déchiffrer — le chiffrement ne requiert que la clef publique de ton correspondant, aucune raison de mettre celle-ci sur un token. Mais je chipote encore (désolé), il est évident que tu parlais de déchiffrer.
D’autre part, on ne déchiffre avec la clef privée rien de plus que la clef de session symétrique avec laquelle on peut ensuite déchiffrer le corps du message. La complexité de l’opération RSA fait que déchiffrer la clef de session est déjà, la plupart du temps, la partie la plus lente (même si le corps du message est beaucoup plus gros que la clef de session, AES est beaucoup plus rapide à déchiffrer, d’autant plus que beaucoup de processeurs ont des instructions AES spécifiques), faire effectuer cette opération par un token ne la ralentit pas beaucoup plus.
C’est une possibilité en effet. Je n’irai pas jusqu’à le recommander, mais c’est une option à considérer en fonction des opposants auxquels on pense faire face.