Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?
J’ai donné l’exemple de OCB2, qui depuis son introduction en 2004 était considéré parfaitement sûr. Puis en 2018, deux attaques coup sur coup : en octobre, une première attaque montre qu’on peut forger des messages (l’algorithme ne garantit pas l’authenticité, contrairement à ce qu’il devrait devrait — en soi c’est déjà une faille énorme, qui aurait été suffisante pour justifier un retrait immédiat de l’algorithme) ; le mois suivant, une autre attaque s’appuie sur la première pour pour casser la confidentialité et permettre de récupérer le texte clair (plaintext recovery attack). Cinq mois plus tard, un papier de synthèse ferme le ban pour ceux qui seraient lents à comprendre : OCB2 est cassé, kaput, les attaques sont praticables et effectives, il ne faut en aucun cas l’utiliser.
(La bonne nouvelle, c’est que quasiment personne n’utilisait OCB2 de toute façon, à cause des brevets qui pesaient dessus...)
Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.
Juste parce que certains algorithmes ont effectivement été lentement érodés avant qu’on ne puisse les considérer comme effectivement vulnérables ne veut pas dire que ce sera systématiquement le cas, et miser là-dessus me semble très risqué.
AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).
Absolument d’accord. Le problème du rejet de l’agilité cryptographique, c’est qu’on passe d’un extrême à l’autre. Avant c’était la foire et on acceptait 72 algorithmes dans le protocole (y compris des perles comme MD5, RC4, 3DES, etc.), maintenant c’est un algorithme epicétou !
On peut supporter l’agilité cryptographique tout en acceptant seulement une petite poignée d’algorithmes soigneusement choisis.
[^] # Re: X25519
Posté par gouttegd . En réponse à la dépêche Sortie de la version 1.0.0 de age. Évalué à 9.
J’ai donné l’exemple de OCB2, qui depuis son introduction en 2004 était considéré parfaitement sûr. Puis en 2018, deux attaques coup sur coup : en octobre, une première attaque montre qu’on peut forger des messages (l’algorithme ne garantit pas l’authenticité, contrairement à ce qu’il devrait devrait — en soi c’est déjà une faille énorme, qui aurait été suffisante pour justifier un retrait immédiat de l’algorithme) ; le mois suivant, une autre attaque s’appuie sur la première pour pour casser la confidentialité et permettre de récupérer le texte clair (plaintext recovery attack). Cinq mois plus tard, un papier de synthèse ferme le ban pour ceux qui seraient lents à comprendre : OCB2 est cassé, kaput, les attaques sont praticables et effectives, il ne faut en aucun cas l’utiliser.
(La bonne nouvelle, c’est que quasiment personne n’utilisait OCB2 de toute façon, à cause des brevets qui pesaient dessus...)
Juste parce que certains algorithmes ont effectivement été lentement érodés avant qu’on ne puisse les considérer comme effectivement vulnérables ne veut pas dire que ce sera systématiquement le cas, et miser là-dessus me semble très risqué.
Absolument d’accord. Le problème du rejet de l’agilité cryptographique, c’est qu’on passe d’un extrême à l’autre. Avant c’était la foire et on acceptait 72 algorithmes dans le protocole (y compris des perles comme MD5, RC4, 3DES, etc.), maintenant c’est un algorithme epicétou !
On peut supporter l’agilité cryptographique tout en acceptant seulement une petite poignée d’algorithmes soigneusement choisis.