Deux questions sur la sécurité du simple DES (56 bits utiles)
1 réponse
EJA
Bonjour,
Je sais qu'une cl=E9 DES a =E9t=E9 cass=E9e pour la premi=E8re fois
(officiellement) en 1997
en 96 jours puis en 1998 (en 2 jours =BD) par un gros ordinateur d=E9di=E9
aid=E9, je
crois, d'un groupe de PC, mais j'aimerai avoir deux =E9claircissements
compl=E9mentaires.
1) Aujourd'hui, 9 ans plus tard, combien de temps environ de temps de
calcul de PC
de g=E9n=E9ration r=E9cente faut-il pour trouver une cl=E9 DES (un PC
pendant x heures
ou x PC pendant 1 heure -> quel est x, environ ?) ?
2) Ind=E9pendamment de cela, si on a une SEULE cha=EEne standard (0 et 1
m=E9lang=E9s, pas
seulement des 0 ou seulement des 1) de 64 bits et sa r=E9sultante via un
simple
DES (de 64 bits =E9galement, donc), la cl=E9 peut-elle en principe =EAtre
trouv=E9e
(avec la puissance de calcul ad=E9quat) ? O=F9 faut-il plusieurs
cha=EEnes et leurs
r=E9sultantes, et dans ce cas combien environ ?
Merci beaucoup =E0 ceux qui peuvent me renseigner.
Cordialement,
Eric JA
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alain
Bonjour, 1) Aujourd'hui, 9 ans plus tard, combien de temps environ de temps de calcul de PC de génération récente faut-il pour trouver une clé DES (un PC pendant x heures ou x PC pendant 1 heure -> quel est x, environ ?) ? dans un livre écrit par bruce scheneir en 95 on lit que la seule attaque
efficace contre le DES est l'attaque brutale, c'est a dire essayer toutes les clés... regerdes leurs performances en chiffrement DES d'un module crypto logiciel (openSSL par ex), c'est a dire combien de Mo/s on peut crypter. En connaissant la quantité de donnée permettant de vérifier si la clé est compatible (si il y a un header fixe au début des données c'est un bloc de 64 bit le minimum) tu peux estimer combien de bloc tu peux déchiffrer et tester par seconde... ce n'est pas exact car le changement de clé est souvent plus couteux que le simple déciffrement à clé fixe, mais pas trop.
sur la page http://homes.esat.kuleuven.be/~bosselae/fast.html on trouve quelque chiffres anciens on a avec un pentium 90Mhz, 4us par bloc et 8 pour la clé... avec le processeur moderne, bi-coeur à plus de 2Ghz, ca irait 40 fois plus vite (bon il faudrait tenir compte de la BP mémoire et de l'architecture du proc)... 300ns par clé testé sur un bloc. 3 million par seconde? ca fait du moins de 760 ans pour casser 56 bits (et 4 jours pour du 40 bits export). moins d'un an avec un millier de processeurs
c'est une grosse louche. je dois être à un facteur 10 près...
en plus avec les processeurs actuel on devrait pouvoir utiliser intelligennt leur unité de calcul bit à bit 64 bits pour faire 64 décryptages à la fois sur 64 clés distinctes...
mais le DES se code difficilement avec des processeurs généralistes. on trouve des cartes efficaces pas trop chères, mais là le changement de clé est parfois très couteux en comparaison.
2) Indépendamment de cela, si on a une SEULE chaîne standard (0 et 1 mélangés, pas seulement des 0 ou seulement des 1) de 64 bits et sa résultante via un simple DES (de 64 bits également, donc), la clé peut-elle en principe être trouvée (avec la puissance de calcul adéquat) ? Où faut-il plusieurs chaînes et leurs résultantes, et dans ce cas combien environ ?
tout dépend de ce que tu connait sur "le clair"...
si tu connais le clair c'est gagné... ca n'a d'intérêt que pour déchiffrer d'autres bloc chiffés avec la même clé.
si tu sait qu'il a le premier octet à zéro, ou les 7 derniers bits à 1, ou que c'est un multiple de 567, tu peux déja éliminer des clés faussses... après tu doit pouvoir détecter de manière fiable si une clé est bonne... c'est a dire si ce que tu a déchiffré est crédible...
si par exempl une clé donne un message NORD et une autre SUD, et que tu cherche a savoir ou l'opposant veux aller, tu n'a pas les moyens de savoir quelle clé est la bonne...
dans la théorie de la crypto (lire les livres classqiues comme cryptography thery and practice, ou applied cryptography) il y a un concept de longuer minimale de chiffré permettant avec une puissance de calcul infinie de découvrir la clé... ca dépend de la redondance du langage du clair... c'est pour ca qu'on conseille de compresser le clair pour qu'il y ait moins de redondance et qu'il faille plus de chiffré pour tester si une clé est bonne...
si ton clair est un nombre réellement alléatoire (genre une clé de session) tu n'a aucun moyen de le vérifier, sauf a tester si il marche .. autant dans ce cas tester tous les clairs possibles pour voir si ils conviennent, sans se fatiguer a tester de clés...
bouquine un peu, c'est pas sorcier à lire si t'as un fond de math correct (et au pire tu ne cherche pas a comprendre les math, mais juste la manière de penser)
Bonjour,
1) Aujourd'hui, 9 ans plus tard, combien de temps environ de temps de
calcul de PC
de génération récente faut-il pour trouver une clé DES (un PC
pendant x heures
ou x PC pendant 1 heure -> quel est x, environ ?) ?
dans un livre écrit par bruce scheneir en 95 on lit que la seule attaque
efficace contre le DES est l'attaque brutale, c'est a dire essayer
toutes les clés...
regerdes leurs performances en chiffrement DES d'un module crypto
logiciel (openSSL par ex), c'est a dire combien de Mo/s on peut crypter.
En connaissant la quantité de donnée permettant de vérifier si la clé
est compatible (si il y a un header fixe au début des données c'est un
bloc de 64 bit le minimum) tu peux estimer combien de bloc tu peux
déchiffrer et tester par seconde...
ce n'est pas exact car le changement de clé est souvent plus couteux que
le simple déciffrement à clé fixe, mais pas trop.
sur la page
http://homes.esat.kuleuven.be/~bosselae/fast.html
on trouve quelque chiffres anciens
on a avec un pentium 90Mhz, 4us par bloc et 8 pour la clé...
avec le processeur moderne, bi-coeur à plus de 2Ghz, ca irait 40 fois
plus vite (bon il faudrait tenir compte de la BP mémoire et de
l'architecture du proc)...
300ns par clé testé sur un bloc. 3 million par seconde?
ca fait du moins de 760 ans pour casser 56 bits (et 4 jours pour du 40
bits export).
moins d'un an avec un millier de processeurs
c'est une grosse louche. je dois être à un facteur 10 près...
en plus avec les processeurs actuel on devrait pouvoir utiliser
intelligennt leur unité de calcul bit à bit 64 bits pour faire 64
décryptages à la fois sur 64 clés distinctes...
mais le DES se code difficilement avec des processeurs généralistes.
on trouve des cartes efficaces pas trop chères, mais là le changement de
clé est parfois très couteux en comparaison.
2) Indépendamment de cela, si on a une SEULE chaîne standard (0 et 1
mélangés, pas
seulement des 0 ou seulement des 1) de 64 bits et sa résultante via un
simple
DES (de 64 bits également, donc), la clé peut-elle en principe être
trouvée
(avec la puissance de calcul adéquat) ? Où faut-il plusieurs
chaînes et leurs
résultantes, et dans ce cas combien environ ?
tout dépend de ce que tu connait sur "le clair"...
si tu connais le clair c'est gagné... ca n'a d'intérêt que pour
déchiffrer d'autres bloc chiffés avec la même clé.
si tu sait qu'il a le premier octet à zéro, ou les 7 derniers bits à 1,
ou que c'est un multiple de 567, tu peux déja éliminer des clés faussses...
après tu doit pouvoir détecter de manière fiable si une clé est bonne...
c'est a dire si ce que tu a déchiffré est crédible...
si par exempl une clé donne un message
NORD et une autre SUD, et que tu cherche a savoir ou l'opposant veux
aller, tu n'a pas les moyens de savoir quelle clé est la bonne...
dans la théorie de la crypto (lire les livres classqiues comme
cryptography thery and practice, ou applied cryptography) il y a un
concept de longuer minimale de chiffré permettant avec une puissance de
calcul infinie de découvrir la clé... ca dépend de la redondance du
langage du clair...
c'est pour ca qu'on conseille de compresser le clair pour qu'il y ait
moins de redondance et qu'il faille plus de chiffré pour tester si une
clé est bonne...
si ton clair est un nombre réellement alléatoire (genre une clé de
session) tu n'a aucun moyen de le vérifier, sauf a tester si il marche
.. autant dans ce cas tester tous les clairs possibles pour voir si ils
conviennent, sans se fatiguer a tester de clés...
bouquine un peu, c'est pas sorcier à lire si t'as un fond de math
correct (et au pire tu ne cherche pas a comprendre les math, mais juste
la manière de penser)
Bonjour, 1) Aujourd'hui, 9 ans plus tard, combien de temps environ de temps de calcul de PC de génération récente faut-il pour trouver une clé DES (un PC pendant x heures ou x PC pendant 1 heure -> quel est x, environ ?) ? dans un livre écrit par bruce scheneir en 95 on lit que la seule attaque
efficace contre le DES est l'attaque brutale, c'est a dire essayer toutes les clés... regerdes leurs performances en chiffrement DES d'un module crypto logiciel (openSSL par ex), c'est a dire combien de Mo/s on peut crypter. En connaissant la quantité de donnée permettant de vérifier si la clé est compatible (si il y a un header fixe au début des données c'est un bloc de 64 bit le minimum) tu peux estimer combien de bloc tu peux déchiffrer et tester par seconde... ce n'est pas exact car le changement de clé est souvent plus couteux que le simple déciffrement à clé fixe, mais pas trop.
sur la page http://homes.esat.kuleuven.be/~bosselae/fast.html on trouve quelque chiffres anciens on a avec un pentium 90Mhz, 4us par bloc et 8 pour la clé... avec le processeur moderne, bi-coeur à plus de 2Ghz, ca irait 40 fois plus vite (bon il faudrait tenir compte de la BP mémoire et de l'architecture du proc)... 300ns par clé testé sur un bloc. 3 million par seconde? ca fait du moins de 760 ans pour casser 56 bits (et 4 jours pour du 40 bits export). moins d'un an avec un millier de processeurs
c'est une grosse louche. je dois être à un facteur 10 près...
en plus avec les processeurs actuel on devrait pouvoir utiliser intelligennt leur unité de calcul bit à bit 64 bits pour faire 64 décryptages à la fois sur 64 clés distinctes...
mais le DES se code difficilement avec des processeurs généralistes. on trouve des cartes efficaces pas trop chères, mais là le changement de clé est parfois très couteux en comparaison.
2) Indépendamment de cela, si on a une SEULE chaîne standard (0 et 1 mélangés, pas seulement des 0 ou seulement des 1) de 64 bits et sa résultante via un simple DES (de 64 bits également, donc), la clé peut-elle en principe être trouvée (avec la puissance de calcul adéquat) ? Où faut-il plusieurs chaînes et leurs résultantes, et dans ce cas combien environ ?
tout dépend de ce que tu connait sur "le clair"...
si tu connais le clair c'est gagné... ca n'a d'intérêt que pour déchiffrer d'autres bloc chiffés avec la même clé.
si tu sait qu'il a le premier octet à zéro, ou les 7 derniers bits à 1, ou que c'est un multiple de 567, tu peux déja éliminer des clés faussses... après tu doit pouvoir détecter de manière fiable si une clé est bonne... c'est a dire si ce que tu a déchiffré est crédible...
si par exempl une clé donne un message NORD et une autre SUD, et que tu cherche a savoir ou l'opposant veux aller, tu n'a pas les moyens de savoir quelle clé est la bonne...
dans la théorie de la crypto (lire les livres classqiues comme cryptography thery and practice, ou applied cryptography) il y a un concept de longuer minimale de chiffré permettant avec une puissance de calcul infinie de découvrir la clé... ca dépend de la redondance du langage du clair... c'est pour ca qu'on conseille de compresser le clair pour qu'il y ait moins de redondance et qu'il faille plus de chiffré pour tester si une clé est bonne...
si ton clair est un nombre réellement alléatoire (genre une clé de session) tu n'a aucun moyen de le vérifier, sauf a tester si il marche .. autant dans ce cas tester tous les clairs possibles pour voir si ils conviennent, sans se fatiguer a tester de clés...
bouquine un peu, c'est pas sorcier à lire si t'as un fond de math correct (et au pire tu ne cherche pas a comprendre les math, mais juste la manière de penser)
