L’agilité cryptographique (le fait de ne pas lier un protocole à un algorithme donné, mais d’offrir une sélection d’algorithmes) n’a plus trop la faveur des cryptologues de nos jours.
C’est essentiellement dû au fait qu’elle impose un mécanisme de négociation (les deux parties à la communication doivent se mettre d’accord sur les algorithmes à utiliser), et qu’un tel mécanisme est une source de complexité et donc de bogues (y compris des bogues résultant en des failles de sécurité). L’exemple typique avancé par les opposants à l’agilité cryptographique est TLS, qui a eu son lot de failles causées par cette étape de négociation.
(OpenPGP n’a à ma connaissance pas trop été affecté par ce genre de problèmes, mais le fait qu’il s’agisse fondamentalement d’un protocole hors-ligne simplifie pas mal la donne : contrairement à TLS ou SSH, la négociation ne se fait pas « en direct », mais seulement par l’intermédiaire des « préférences algorithmiques » portées par la clef du destinataire.)
Le credo de beaucoup de cryptologues est désormais : « Mettez tous vos œufs dans le même panier et surveillez ce panier comme la prunelle de vos yeux ! »
Pour ce que ça vaut, je ne suis personnellement pas convaincu par cette approche et pense que l’agilité cryptographique reste souhaitable (et je me réjouis que la future version d’OpenPGP n’y renonce pas), pour plusieurs raisons.
Ça veut dire quoi, « surveiller un algorithme » ? ce n’est pas en « surveillant » en algorithme que l’on va empêcher un cryptanalyste quelque part dans le monde d’y découvrir une faille. On peut bien demander à Matthew Green, Daniel Bernstein, Adi Shamir et Whitfield Diffie de monter la garde autour de la description de X25519 ou de AES, quelle « protection » ça apportera ?
L’idée est que si une faille dans l’algorithme sanctifié est découverte, on publie une nouvelle version du protocole avec un nouvel algorithme. Comme ça tout le monde bascule d’un coup vers le nouveau protocole et le nouvel algorithme sanctifié, et on ne se traîne pas un algorithme que l’on sait vulnérable. Un simple coup d’œil à l’histoire des transitions protocolaires (ne serait-ce que TLS, justement) me pousse à croire que penser qu’on peut forcer tout le monde à « basculer d’un coup » est complètement irréaliste.
En filigrane, derrière ce rejet de l’agilité cryptographique j’ai aussi l’impression de voir une très (trop ?) grande confiance dans les algorithmes choisis, comme si cette fois c’était la bonne, oui, on a eu des algorithmes qui se sont révélés mauvais par le passé mais là vraiment, X25519, Chacha20, Poly1305 c’est des bons, on peut vraiment miser dessus, la probabilité qu’on doive les changer un jour (et donc passer par une transition à une nouvelle version du protocole) est très faible. Si c’est le cas (et que ce n’est donc pas que mon impression), je ne suis pas sûr qu’une telle confiance soit opportune. On a justement eu suffisamment d’exemples d’algorithmes que l’on croyait à un moment très sûr jusqu’à ce qu’on réalise qu’ils ne l’étaient pas tant que ça... J’ai déjà évoqué récemment par ici le cas d’OCB2, que pendant près de quinze ans tout le monde pensait complètement sûr (« preuve de sécurité » à l’appui), jusqu’à ce qu’il se fasse démonter en seulement quelques mois...
[^] # Re: X25519
Posté par gouttegd . En réponse à la dépêche Sortie de la version 1.0.0 de age. Évalué à 10.
L’agilité cryptographique (le fait de ne pas lier un protocole à un algorithme donné, mais d’offrir une sélection d’algorithmes) n’a plus trop la faveur des cryptologues de nos jours.
C’est essentiellement dû au fait qu’elle impose un mécanisme de négociation (les deux parties à la communication doivent se mettre d’accord sur les algorithmes à utiliser), et qu’un tel mécanisme est une source de complexité et donc de bogues (y compris des bogues résultant en des failles de sécurité). L’exemple typique avancé par les opposants à l’agilité cryptographique est TLS, qui a eu son lot de failles causées par cette étape de négociation.
(OpenPGP n’a à ma connaissance pas trop été affecté par ce genre de problèmes, mais le fait qu’il s’agisse fondamentalement d’un protocole hors-ligne simplifie pas mal la donne : contrairement à TLS ou SSH, la négociation ne se fait pas « en direct », mais seulement par l’intermédiaire des « préférences algorithmiques » portées par la clef du destinataire.)
Le credo de beaucoup de cryptologues est désormais : « Mettez tous vos œufs dans le même panier et surveillez ce panier comme la prunelle de vos yeux ! »
Pour ce que ça vaut, je ne suis personnellement pas convaincu par cette approche et pense que l’agilité cryptographique reste souhaitable (et je me réjouis que la future version d’OpenPGP n’y renonce pas), pour plusieurs raisons.
Ça veut dire quoi, « surveiller un algorithme » ? ce n’est pas en « surveillant » en algorithme que l’on va empêcher un cryptanalyste quelque part dans le monde d’y découvrir une faille. On peut bien demander à Matthew Green, Daniel Bernstein, Adi Shamir et Whitfield Diffie de monter la garde autour de la description de X25519 ou de AES, quelle « protection » ça apportera ?
L’idée est que si une faille dans l’algorithme sanctifié est découverte, on publie une nouvelle version du protocole avec un nouvel algorithme. Comme ça tout le monde bascule d’un coup vers le nouveau protocole et le nouvel algorithme sanctifié, et on ne se traîne pas un algorithme que l’on sait vulnérable. Un simple coup d’œil à l’histoire des transitions protocolaires (ne serait-ce que TLS, justement) me pousse à croire que penser qu’on peut forcer tout le monde à « basculer d’un coup » est complètement irréaliste.
En filigrane, derrière ce rejet de l’agilité cryptographique j’ai aussi l’impression de voir une très (trop ?) grande confiance dans les algorithmes choisis, comme si cette fois c’était la bonne, oui, on a eu des algorithmes qui se sont révélés mauvais par le passé mais là vraiment, X25519, Chacha20, Poly1305 c’est des bons, on peut vraiment miser dessus, la probabilité qu’on doive les changer un jour (et donc passer par une transition à une nouvelle version du protocole) est très faible. Si c’est le cas (et que ce n’est donc pas que mon impression), je ne suis pas sûr qu’une telle confiance soit opportune. On a justement eu suffisamment d’exemples d’algorithmes que l’on croyait à un moment très sûr jusqu’à ce qu’on réalise qu’ils ne l’étaient pas tant que ça... J’ai déjà évoqué récemment par ici le cas d’OCB2, que pendant près de quinze ans tout le monde pensait complètement sûr (« preuve de sécurité » à l’appui), jusqu’à ce qu’il se fasse démonter en seulement quelques mois...