Salut,

Je suis en train de consulter mes comptes sur le site de ma banque lorsque, pris d'un doute, je consulte les paramètres de chiffrement. Et là, horreur ! Il ne chiffre qu'avec 56 bits.

Question : C'est grave docteur ? Ou, vu que la communication va être courte, 56 bits c'est suffisant ?

_{Fred --
jeune padawan}

C'est peut-être grave, mais vu qu'il me semble que c'est le serveur Web de la banque qui décide (sauf erreur de ma part) on n'y peut pas grand chose.


Celà étant 56 bits, c'est vraiement pas cher: peut-être _{mode parano = on} l'Etat français impose aux banques de crypter faiblement?

Il parait que les 128 bits d'un cryptage WEP se casse en quelques minutes, alors 56 bits bof bof...


----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Basile STARYNKEVITCH a écrit :

ce ne sont pas les même : les 128 bits du wep se crackent très vite car il "suffit" de capturer suffisament de trames pour flinguer la clef. Rien à voir avec les 128bits du cryptage ssl pour lesquel la capture de trame ne permet pas de catalyser le crackage.


Pour les 56bits, doit y avoir une feinte à comprendre ; mais là désolé, pour ma part je ne sais pas l'expliquer.

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Attention, Basile, le nombre de bits sur lesquels on chiffre la communication n'est pas le seul paramètre à prendre en compte. Il faut aussi voir quel algorithme est utilisé ! (Cf [fr.wikipedia.org])

Fred, en fonction de la banque (je ne sais pas si toutes le font, etc.) tu peux restreindre les opérations bancaires sur tes seuls comptes, en d'autres termes interdire les opérations vers d'autres comptes. Pour la gestion via internet c'est plus sécurisé d'une certaine manière.
Cela dit, c'est vrai que ma banque allemande (je travaille en Allemagne, d'où nécessité d'un compte dans ce pays) demande un code à 4 chiffres désigné dans une liste numérotée pour chaque opération, du simple changement de mot de passe au virement international. Evidemment tout cela se passe au-dessus de SSL.

Toutefois c'est une bonne chose de se poser la question.

___________________________________________________________________
_{.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --}

Score de rapidité (euh... synchronisation) :
Tuxfanch : 1 - merlin8282 : 0

___________________________________________________________________
_{.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --}

Merci pour vos explications; je me suis emmelé les pinceaux! Désolé...



----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

En plus comparer les tailles de clés n'est vraiment pas pertinent....

Dans le cas de protocole à clé symétrique comme WEP, il faut essayer toutes les clés, pas d'autres solution... 2^218 choix pour une clé de 218 bits.
Sauf que biensur comme l'a rappelé tuxfanch, des failles dans le protocole permettent d'être malin et donc d'essayer les clés dans un ordre intelligent et trouver la clé dans les premiers essais

Pour les protocoles à clé asymétrique, l'algorithme repose sur des propriétés mathématiques et on peut en profiter pour simplifier le problème ... Concretement, on peut casser une clé sans essayer toutes les clés. Donc le nombre de calculs pour casser une clé asymétrique de 218 bits n'est pas comparable à celui pour casser une clé symétrique de 218 bits.

Après dans le même registre, selon le principe de l'algorithme à clé asymétrique, la taille de la clé ne represente pas la même quantité de calcul nécessaire pour casser la clé.

Enfin, truc tout bête, c'est pas parceque on a un moyen de chiffrer super puissant, que forcement le numéro de ta carte bleu ne sera pas lu par un intrus. Ca dépend énorment du protocole qui va échanger les données... il existe tout un domaine de la recherche (très proche de la logique d'ailleurs) qui étudie si tel ou tel protocole rempli telle ou telle propriété (preservation des données, anonymat, authentification etc ...)
L'exemple le plus connu [fr.wikipedia.org]Échange_de_clés_Diffie-Hellman... même avec des clés de 1 milliars de bits, ce protocole n'est pas sur.

Bref se méfier des jugements rapides... rien n'est simple

Il n'empèche, 2^56 n'est pas un nombre irréalisable pour une attaque de force brute ...

Dans le même registre, je pensais à quelque chose : il y a des concours (avec des lots importants) sur le net pour chercher des grands nombres premiers pour améliorer la cryptographie (pas mal d'algorithmes se basent sur la factorisation par un premier). Or, il y a des nombres beaucoup plus susceptibles que d'autres d'être premiers : les nombres de Mersenne (2^p-1 avec p premier). En plus, il est assez facile de savoir si un tel nombre est effectivement premier : il suffit qu'il divise un autre nombre facile à calculer par récurrence ...

Tout ça pour dire quoi ? Qu'en fin de compte, la recherche de grands premiers se limite quasiment de nos jours à celle de grands nombres de Mersenne ... c'est tellement plus simple !
Sauf qu'en cryptographie ça présente moins d'intéret ! Et oui, une fois qu'on le sait, pourquoi ne pas faire une attaque de force brute uniquement sur les nombres de Mersenne ? Ca diminue beaucoup la complexité de l'algorithme nécessaire, donc le temps de calcul pour le cassage, non ?

Voilà, je voulais savoir ce que vous en pensiez, parce que pour moi c'est un des paradoxes de la cryptographie ...

[catwell.info]

Il n'y a que 43 nombres de Mersenne connus aujourd'hui ... [www.mersenne.org]

Je ne suis donc pas persuadé que les nombres utilisés dans la crypto soit que des nombres de Mersenne.

AlSim a écrit :

Faisons le calcul de l'ordre de grandeur pour énumérer toutes les clés

-> (2^56)/vitesse(en flops)

D'après le TOP500
BlueGene (N°1 du classement) = 280TFlops/s => 4 minutes
Premiere machine francais (N° 62) = 5,8 TFlops/s => presque 3h30

C'est pas encore monsieur et madame tout le monde qui peut casser une telle clé en 5 minutes....

mais ces temps ca part du principe que c'est une attaque en brute force. Tous les algos de cryptage ont leurs faiblesses, et il n'y a pas besoin de passer par le brute force pour les casser : il suffit de trouver un algo plus performant (je te renvoie à pléthore de sites qui en aprlent).
Ceci dit, j'ai peur que ton calcul avec les flops soit très approximatif : calculer (2^X) * 2 ce c'est pas un flop a priori !!

ps: bonjour tout le monde, ca fait plaisir de revenir ici ca faisait longtemps

Léa (maston28) a écrit :

Oui bien sur, j'ai bien précisé que c'était pour une attaque en force brute.

Et je suis d'accord aussi que prendre 1 flop par clé possible est assez léger... il y a plein d'autres choses qui rentrent en jeu et qui nécessitent des calculs(communications entre processeurs sur ce genre de machines, accès à la mémoire, même tester la clé.)... Tout ca tend plutot à dire, que dans le cas d'une attaque à force brute, je sous-estime les temps de calcul. Donc casser une clé de 56 bits par force brute n'est vraiment pas facile...
Bref, on a bien que:
- 56 bits c'est déjà pas mal.
- On ne mesure pas la sécurité d'un chiffrement par la taille de sa clé

Je sens qu'on va me faire la remarque, donc j'anticipe...

Je sais aussi qu'un flop c'est pour une opération flottante et pas pour une instruction...

Mais (je peux me tromper), ca donne une bonne idée de la puissance de calcul et c'est pour ca que je compare les machines par rapport à leur puissance en flops(de toute façon, c'est la seule information un peu pertinente qui permet de comparer ce genre de machine...)

Kynes a écrit :

-56 bits ca serait déja pas mal si les algos de chiffrement les plus courants n'avaient pas tous été cassés en peu de temps en 56bits. Donc 56bits c'est peu, étant donné qu'on a pas d'algo assez solides :).

-On ne mesure pas la sécurité d'un chiffrement par la taille de sa clé...oui et non, facile à comprendre après ce que je viens de dire je pense .

En l'occurrence, Konqueror me dit qu'il s'agit de l'algo de chiffrage?/cryptage? : DES-CBC-SHA.

C'est cassé le DES ?

_{Fred --
jeune padawan}

Je me réponds, après lecture des articles :

• [fr.wikipedia.org]
• [fr.wikipedia.org]

et de cette doc : [www.redhat.com] qui dit que l'algo DES-CBC-SHA c'est du DES simple.

Bref: ma banque utilise un algo à sécurité 'medium' (cf l'article de www.redhat.com plus haut).

La question que je pose donc, c'est : est-ce un problème, lors qu'une communication https d'utiliser ce type d'algo, sachant que le site me redemande une authentification toutes les 5 min environ.

_{Fred --
jeune padawan}

bah ca veut dire qu'il faut qu'un attaquant capture le traffic, l'analyse, le casse, et l'exploite (transfert de fonds depuis tes millions vers son compte en suisse), en moins de 5 minutes.

bin non, ça c'est pas possible, même moi je ne peux faire que des virement inter-compte de mon abonnement. Pour les virements inter-compte hors abonnement, il faut que je fasse valider le compte destinataire par une autre procédé.

_{Fred --
jeune padawan}

Léa (maston28) a écrit :

... oui !
Bon retour, alors .

[catwell.info]