Supporter l’agilité cryptographique n’implique aucunement de laisser les administrateurs et/ou les utilisateurs décider de l’algorithme à utiliser.
Ce n’est pas parce que c’est comme ça qu’on a fait avec TLS que c’est inhérent au principe de l’agilité cryptographique. (Tous les arguments que j’ai lu contre l’agilité cryptographique sont du même tonneau : on a magistralement foiré l’agilité cryptographique dans (TLS|JWT|SSH|...), du coup il ne faut plus d’agilité du tout...)
Disons que le protocole autorise trois algorithmes différents A, B, et C, et recommande l’algorithme A.
Alice utilise un logiciel supportant les trois algorithmes. Bob utilise un autre logiciel supportant aussi les trois algorithmes. Quand ils se parlent, leurs logiciels s’échangent la liste des algorithmes supportés et, constatant la présence de l’algorithme A des deux côtés, utilisent obligatoirement A, sans que jamais Alice et Bob n’aient leur mot à dire.
On découvre une faille dans l’algorithme A, les auteurs du protocole recommandent désormais l’algorithme B. Alice met à jour son logiciel pour une nouvelle version dans laquelle l’algorithme A est désactivé. Bob n’a pas encore mis à jour (l’éditeur de son logiciel n’a pas encore publié de nouvelle version). Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.
Plus tard, Bob met à jour, sa nouvelle version ne supporte plus que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.
Plus tard encore, les auteurs du protocole rajoutent un algo D, et décident qu’il est tellement mieux que les autres qu’il devrait désormais être utilisé partout où c’est possible.
Cette fois l’éditeur du logiciel de Bob est plus rapide et publie une nouvelle version avec le support de D. Alice, elle, reste temporairement avec une version qui ne supporte toujours que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.
Alice met à jour, son logiciel supporte désormais B, C, et D. Alice et Bob utilisent désormais automatiquement D chaque fois qu’ils se parlent.
Et ainsi de suite. À aucun moment Alice et Bob ne peuvent configurer leurs logiciels pour décider eux-mêmes de l’algorithme à utiliser. Le choix est imposé par les logiciels, en fonction des recommandations des auteurs du protocole et de ce que supporte le logiciel d’en face.
[^] # Re: Une seule suite crypto ?
Posté par gouttegd . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 10.
Supporter l’agilité cryptographique n’implique aucunement de laisser les administrateurs et/ou les utilisateurs décider de l’algorithme à utiliser.
Ce n’est pas parce que c’est comme ça qu’on a fait avec TLS que c’est inhérent au principe de l’agilité cryptographique. (Tous les arguments que j’ai lu contre l’agilité cryptographique sont du même tonneau : on a magistralement foiré l’agilité cryptographique dans (TLS|JWT|SSH|...), du coup il ne faut plus d’agilité du tout...)
Disons que le protocole autorise trois algorithmes différents A, B, et C, et recommande l’algorithme A.
Alice utilise un logiciel supportant les trois algorithmes. Bob utilise un autre logiciel supportant aussi les trois algorithmes. Quand ils se parlent, leurs logiciels s’échangent la liste des algorithmes supportés et, constatant la présence de l’algorithme A des deux côtés, utilisent obligatoirement A, sans que jamais Alice et Bob n’aient leur mot à dire.
On découvre une faille dans l’algorithme A, les auteurs du protocole recommandent désormais l’algorithme B. Alice met à jour son logiciel pour une nouvelle version dans laquelle l’algorithme A est désactivé. Bob n’a pas encore mis à jour (l’éditeur de son logiciel n’a pas encore publié de nouvelle version). Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.
Plus tard, Bob met à jour, sa nouvelle version ne supporte plus que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.
Plus tard encore, les auteurs du protocole rajoutent un algo D, et décident qu’il est tellement mieux que les autres qu’il devrait désormais être utilisé partout où c’est possible.
Cette fois l’éditeur du logiciel de Bob est plus rapide et publie une nouvelle version avec le support de D. Alice, elle, reste temporairement avec une version qui ne supporte toujours que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.
Alice met à jour, son logiciel supporte désormais B, C, et D. Alice et Bob utilisent désormais automatiquement D chaque fois qu’ils se parlent.
Et ainsi de suite. À aucun moment Alice et Bob ne peuvent configurer leurs logiciels pour décider eux-mêmes de l’algorithme à utiliser. Le choix est imposé par les logiciels, en fonction des recommandations des auteurs du protocole et de ce que supporte le logiciel d’en face.