"(PQ)-Cryptography" n'est utilisé ni dans le lien ni ailleurs genre Wikipedia, ça sort d'où?
Et il y avait la place pour écrire en version longue plus lisible.
De (faibles, certes) lectures que j'en ai le diminutif que je vois est plutôt "PQCrypto" (d'où les conférences avec le nom).
En tous cas, on peut surtout constater que les chercheurs en cryptographie post-quantique ont un petit problème dans leur travaux ayant pour but de se protéger des attaques avec un matériel futur pour comprendre et se protéger des attaques avec du matériel actuel…
"demolition derby" sont de si jolis mots, mais ça doit faire mal à ceux qui se font exploser… Et il faut surtout en retenir qu'il faut éviter de n'avoir qu'un standard supporté partout, mais imposer (comment) les outils à accepter dès le départ plusieurs standards au cas où un se fait démolir quelques années après le choix (car ça arrivera vu ce qui a déjà été trouvé avant le choix).
Et il faut surtout en retenir qu'il faut éviter de n'avoir qu'un standard supporté partout, mais imposer (comment) les outils à accepter dès le départ plusieurs standards
Pour info, on a très bien su le faire jusqu’à présent. La plupart des protocoles impliquant de la crypto (TLS, SSH, OpenPGP…) supportent la notion d’agilité cryptographique : ils ne sont pas liés à un algorithme précis, mais permettent de choisir un algorithme de chaque type (algo d’échange de clefs, algo d’authentification, algo de chiffrement symétrique, algo de vérification d’intégrité) dans une liste d’algorithmes possibles.
Par contre, ça fait plusieurs années que pas mal de cryptologues critiquaient justement l’agilité cryptographique. Ça introduit de la complexité (notamment puisqu’il faut une étape de négociation à un moment donné pour que les différentes parties à la communication se mettent d’accord sur quels algorithmes elles vont utiliser, parmi ceux disponibles), et donc des risques accrus de bugs – y compris des bugs qui peuvent permettre de casser la confidentialité normalement apportée par la cryptographie…
Face à ces bugs, de nombreux cryptologues ont appelé à la fin de l’agilité cryptographique, en expliquant qu’il était désormais préférable de choisir une bonne fois pour toute un algo, et de se débarasser de toute la complexité liée à l’agilité.
Personnellement je n’ai jamais été convaincu par cette approche « tout miser sur un algo », je me suis réjoui de voir que les auteurs de protocoles ne semblaient pas y adhérer, et je me réjouis de voir Schneier souligner la nécessité de l’agilité cryptographique.
Je vois pas en quoi ça change fondamentalement les choses, tu aura une négociation pour la version du protocole plutôt que pour les algo. C'est peut être un peu plus simple pour l'utilisateur car c'est plus simple de dire on passe en TLS 1.2 minimum, mais fondamentalement c'est le même problème, non ?
Posté par gouttegd .
Évalué à 4.
Dernière modification le 09 août 2022 à 18:01.
Oui, parce que s’il y a une chose que l’histoire des trente dernières années nous a apprise, c’est que c’est très facile de passer d’une version d’un protocole à une autre, finger in the nose …
(Pour rappel, on est ici sur un site qui ne supporte ni IPv6 ni TLS 1.3.)
With versioned protocols instead of cipher agility: If a vulnerability is discovered in protocol version 1, you simply upgrade to protocol version 2.
Cacher derrière ce simply toute la difficulté des transitions protocolaires est d’une malhonnêteté crasse.
Surtout quand on parle de protocoles cryptographiques, avec TLS qui nous donne justement un très bel exemple d’un protocole où la gestion de la version du protocole a été magistralement foirée (ce qui a rendu possible toute une série de protocole downgrade attacks).
sans laisser l'utilisateur final se tirer une balle dans le pied.
Supporter l’agilité cryptographique ne signifie pas nécessairement « laisser l’utilisateur se tirer une balle dans le pied ». On peut supporter plusieurs algorithmes sans pour autant laisser à l’utilisateur le soin de choisir lequel utiliser.
Supporter l’agilité cryptographique ne signifie pas nécessairement « laisser l’utilisateur se tirer une balle dans le pied ». On peut supporter plusieurs algorithmes sans pour autant laisser à l’utilisateur le soin de choisir lequel utiliser.
Oui, on peut. J'ai l'impression que l'appel à la fin de l'agilité cryptographique a été une réaction épidermique à la bien trop grande liberté qui était donnée (coucou les protocoles avec des clefs à 64bits ou carrément le chiffrement nul). Je ne dis pas que c'est une bonne réaction mais il faut comprendre d'où ça vient. Et d'ailleurs, ça reste non trivial d'avoir une liste d'algo configurée pour Apache par exemple (la méthode la plus simple que je connaisse, c'est de copier la conf fournie par Mozilla en mode boîte noire). Les choses bougent j'ai l'impression, mais on revient quand même de très loin (c'est-dire que c'était très facile de se tirer une balle dans le pied quand ce n'était pas la conf par défaut).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# "(PQ)"?
Posté par Zenitram (site web personnel) . Évalué à 3.
"(PQ)-Cryptography" n'est utilisé ni dans le lien ni ailleurs genre Wikipedia, ça sort d'où?
Et il y avait la place pour écrire en version longue plus lisible.
De (faibles, certes) lectures que j'en ai le diminutif que je vois est plutôt "PQCrypto" (d'où les conférences avec le nom).
En tous cas, on peut surtout constater que les chercheurs en cryptographie post-quantique ont un petit problème dans leur travaux ayant pour but de se protéger des attaques avec un matériel futur pour comprendre et se protéger des attaques avec du matériel actuel…
"demolition derby" sont de si jolis mots, mais ça doit faire mal à ceux qui se font exploser… Et il faut surtout en retenir qu'il faut éviter de n'avoir qu'un standard supporté partout, mais imposer (comment) les outils à accepter dès le départ plusieurs standards au cas où un se fait démolir quelques années après le choix (car ça arrivera vu ce qui a déjà été trouvé avant le choix).
[^] # Re: "(PQ)"?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Titre modifié et langue corrigée
[^] # Re: "(PQ)"?
Posté par gouttegd . Évalué à 8.
Pour info, on a très bien su le faire jusqu’à présent. La plupart des protocoles impliquant de la crypto (TLS, SSH, OpenPGP…) supportent la notion d’agilité cryptographique : ils ne sont pas liés à un algorithme précis, mais permettent de choisir un algorithme de chaque type (algo d’échange de clefs, algo d’authentification, algo de chiffrement symétrique, algo de vérification d’intégrité) dans une liste d’algorithmes possibles.
Par contre, ça fait plusieurs années que pas mal de cryptologues critiquaient justement l’agilité cryptographique. Ça introduit de la complexité (notamment puisqu’il faut une étape de négociation à un moment donné pour que les différentes parties à la communication se mettent d’accord sur quels algorithmes elles vont utiliser, parmi ceux disponibles), et donc des risques accrus de bugs – y compris des bugs qui peuvent permettre de casser la confidentialité normalement apportée par la cryptographie…
Face à ces bugs, de nombreux cryptologues ont appelé à la fin de l’agilité cryptographique, en expliquant qu’il était désormais préférable de choisir une bonne fois pour toute un algo, et de se débarasser de toute la complexité liée à l’agilité.
Personnellement je n’ai jamais été convaincu par cette approche « tout miser sur un algo », je me suis réjoui de voir que les auteurs de protocoles ne semblaient pas y adhérer, et je me réjouis de voir Schneier souligner la nécessité de l’agilité cryptographique.
[^] # Agilité cryptographique
Posté par Samuel (site web personnel) . Évalué à 1.
Des critiques de l'agilité cryptographique (par exemple Against Cipher Agility in Cryptography Protocols, paragon IE, en), je retiens surtout la proposition d'utiliser des protocoles versionnés, par exemple dans la présentation de paseto, un concurrent à JWT/Jose (en) :
Ça représente une forme de souplesse cryptographique (= on peut déprécier un algo) sans laisser l'utilisateur final se tirer une balle dans le pied.
[^] # Re: Agilité cryptographique
Posté par barmic 🦦 . Évalué à 2.
Je vois pas en quoi ça change fondamentalement les choses, tu aura une négociation pour la version du protocole plutôt que pour les algo. C'est peut être un peu plus simple pour l'utilisateur car c'est plus simple de dire on passe en TLS 1.2 minimum, mais fondamentalement c'est le même problème, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Agilité cryptographique
Posté par gouttegd . Évalué à 4. Dernière modification le 09 août 2022 à 18:01.
Oui, parce que s’il y a une chose que l’histoire des trente dernières années nous a apprise, c’est que c’est très facile de passer d’une version d’un protocole à une autre, finger in the nose …
(Pour rappel, on est ici sur un site qui ne supporte ni IPv6 ni TLS 1.3.)
Cacher derrière ce simply toute la difficulté des transitions protocolaires est d’une malhonnêteté crasse.
Surtout quand on parle de protocoles cryptographiques, avec TLS qui nous donne justement un très bel exemple d’un protocole où la gestion de la version du protocole a été magistralement foirée (ce qui a rendu possible toute une série de protocole downgrade attacks).
Supporter l’agilité cryptographique ne signifie pas nécessairement « laisser l’utilisateur se tirer une balle dans le pied ». On peut supporter plusieurs algorithmes sans pour autant laisser à l’utilisateur le soin de choisir lequel utiliser.
[^] # Re: Agilité cryptographique
Posté par claudex . Évalué à 5.
Oui, on peut. J'ai l'impression que l'appel à la fin de l'agilité cryptographique a été une réaction épidermique à la bien trop grande liberté qui était donnée (coucou les protocoles avec des clefs à 64bits ou carrément le chiffrement nul). Je ne dis pas que c'est une bonne réaction mais il faut comprendre d'où ça vient. Et d'ailleurs, ça reste non trivial d'avoir une liste d'algo configurée pour Apache par exemple (la méthode la plus simple que je connaisse, c'est de copier la conf fournie par Mozilla en mode boîte noire). Les choses bougent j'ai l'impression, mais on revient quand même de très loin (c'est-dire que c'était très facile de se tirer une balle dans le pied quand ce n'était pas la conf par défaut).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.