La cryptographie était à l'ordre du jour à Amsterdam du 13 au 15 avril lors d'un nouveau symposium sur la cryptographie dans le monde réel, organisé à la fois en personne et en ligne. Lisez le blog de David Hook, de Keyfactor, pour en savoir plus sur les trois principaux enseignements qu'il a tirés de cet événement.
En résumé, il se passe beaucoup de choses ! Pour ceux d'entre vous qui recherchent des détails plus approfondis sur les choses qui nous affectent à court terme, j'ai pensé examiner trois sujets d'intérêt : le concours PQC du NIST se poursuit, les listes de révocation de certificats (CRL) sont toujours d'actualité, et l'idée de la crypto-agilité en tant que principe s'avère beaucoup plus impliquée que nous ne l'avions imaginé au départ.
Le concours PQC du NIST se poursuit
À la fin de l'année dernière, il a été annoncé que le jeu d'algorithmes final du concours PQC du NIST serait choisi à la fin du mois de mars de cette année. Comme l'a si bien dit un orateur, nous sommes aujourd'hui à la fin du mois de mars, pour de très grandes valeurs de retard. Le NIST n'a pas fait d'autres annonces et les équipes de soumission ne semblent pas avoir plus d'informations non plus.
Cette pause peut s'expliquer par les progrès réalisés dans l'analyse des candidats. Une attaque contre Rainbow a eu pour effet de réduire d'un niveau la sécurité de tous ses ensembles de paramètres. Plus récemment, une attaque améliorée par double treillis a été publiée, qui réduit également la sécurité d'algorithmes tels que SABER, Crystals-Dilithium et Crystals-Kyber.
Cela ne signifie pas que l'un de ces algorithmes est intrinsèquement défectueux, mais cela peut signifier que la taille des paramètres doit être révisée, ce qui a des répercussions sur l'utilité des algorithmes qui, à leur tour, affectent probablement l'aptitude d'un algorithme à être sélectionné. Alors peut-être - juste peut-être - que le NIST est en train de réfléchir un peu plus.
Une chose semble claire : la "forme", pour ainsi dire, des algorithmes vers lesquels nous migrerons à l'avenir ne semble pas devoir changer. Nous y reviendrons un peu plus tard !
Les LCR existent toujours
En ce qui concerne la CRL, Mike Hamburg a parlé de la redécouverte de la CRL. Pour ceux qui viennent de nous rejoindre, voici un bref historique. Lorsque les LCR ont commencé à devenir assez volumineuses, du moins pour certaines autorités de certification et leurs utilisateurs, l'idée de consulter le statut en ligne - par opposition à la distribution des LCR complètes - est apparue avec l'OCSP (Online Certificate Status Protocol). Comme la plupart des bonnes idées, celle-ci a conduit à d'autres problèmes, qui ont abouti à l'agrafage OCSP.
L'éléphant dans la pièce avec OCSP a toujours été ce qu'il faut faire lorsque le serveur OCSP est en panne. Il y a eu quelques incidents où nous l'avons découvert, le plus célèbre étant probablement celui qui a donné lieu à des blogs aux titres remarquablement succincts tels que "Qu'est-il arrivé à mon Mac ? L'apocalypse OCSP d'Apple".
L'exposé de Mike a jeté un regard neuf sur CRLite, une proposition déjà active visant à revenir à un équivalent téléchargé localement pour une CRL. Elle a été proposée à l'origine en 2017 et fournit une représentation beaucoup plus petite. Bien que CRLite ne fournisse pas autant d'informations qu'une CRL réelle, il vous indique si un certificat est révoqué, ce qui, dans la plupart des cas, est tout ce qui est nécessaire. Il s'avère que seuls quelques pour cent des certificats sont révoqués, ce qui fait de l'utilisation de cartes filtrantes telles que les filtres de Bloom un moyen efficace de représenter une CRL avec une réduction substantielle de la taille. Et il semble que les filtres à ruban effiloché produisent une empreinte encore plus petite. La taille des structures résultantes semble les rendre faciles à télécharger. CRLite, tel qu'il est décrit, est beaucoup plus large qu'une seule LCR pour une seule autorité de certification, mais les leçons et les techniques apprises sont également applicables à une seule autorité de certification. Si la gestion et l'émission de LCR vous intéressent, ce travail mérite d'être suivi.
La crypto-agilité n'est pas aussi simple qu'il n'y paraît
Enfin, il y a eu une série d'exposés sur tout ce qui concerne le post-quantique (PQ), qui s'est terminée par un exposé sur la transition et l'agilité cryptographiques. Je vais paraphraser un peu pour faire court, donc si je n'ai pas tout à fait saisi ce que David Ott et ses co-auteurs essayaient de faire passer, j'espère qu'ils accepteront mes excuses.
Nous parlons beaucoup de la crypto-agilité, mais bien que certains aient essayé de souligner que ce n'est pas aussi facile que cela en a l'air, beaucoup d'entre nous semblent encore penser que c'est comme pour le passage à l'an 2000 : il suffit d'auditer vos bases de données et d'ajuster ces lectures et comparaisons de deux colonnes, et tout va bien. Il est devenu évident que ce n'est pas le cas. Comme l'a souligné l'animateur d'une session, il ne suffit pas d'ajouter PQ au début du protocole pour s'attendre à ce qu'il fonctionne. Tous les nouveaux algorithmes ne correspondent pas directement aux méthodes que nous utilisons actuellement et, en tant qu'industrie, nous sommes encore en train de déterminer de quel côté de la ligne se situent les différents protocoles - pour certains, il s'agit de modifications mineures et vous avez ajouté la PQ. Pour d'autres, pour citer une célèbre phrase de Star Trek, il s'agit vraiment d'un cas de "c'est la vie Jim, mais pas comme nous la connaissons".
Cela dit, il semble que nous ayons une bonne idée des caractéristiques des "nouveaux" algorithmes, de sorte qu'en ce qui concerne l'expérimentation, il n'est pas nécessaire d'attendre la publication des normes finales. Nous pouvons commencer dès maintenant. Ceci est particulièrement important pour les personnes qui envisagent le chiffrement hybride (comme la combinaison d'un algorithme classique tel que ECCDH avec un algorithme PQC tel que FrodoKEM), car cela implique un changement dans la façon dont les choses sont faites.
Enfin, j'aimerais mentionner que la version 1.71 de Bouncy Castle , qui vient d'être publiée, intègre quatre des finalistes et candidats alternatifs du NIST : FrodoKEM, Classic McEliece, SABER et SPHINCS+, ainsi que la prise en charge d'une classe HybridValueParameterSpec permettant d'utiliser la sortie des algorithmes KEM pour le chiffrement hybride. Les mêmes algorithmes seront bientôt disponibles sur Bouncy Castle pour C#. Avec un peu d'aide extérieure, nous espérons que les implémentations des autres algorithmes seront terminées au cours des prochains mois. Si vous souhaitez commencer à étudier ces algorithmes, certaines ressources sont déjà disponibles, et les ressources manquantes arrivent.
Si vous voulez commencer à essayer Bouncy Castle , consultez les liens suivants :
