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 [v]mode parano = on[/v] 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

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

Projet logiciel libre: RefPerSys

Poste le Wednesday 19 April 2006 18:50:08

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

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

Poste le Wednesday 19 April 2006 22:26:44

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 --

Poste le Wednesday 19 April 2006 22:31:00

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 --

Poste le Wednesday 19 April 2006 22:32:31

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



----

Basile STARYNKEVITCH

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

Projet logiciel libre: RefPerSys

Poste le Wednesday 19 April 2006 23:16:39

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 #%b

Poste le Sunday 23 April 2006 12:56:06

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]

Poste le Sunday 23 April 2006 13:29:11

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.

Poste le Sunday 23 April 2006 14:08:19

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

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....

Poste le Sunday 23 April 2006 14:26:48

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 ^^D-*^^D-*

Poste le Monday 24 April 2006 23:06:52

Citation
Léa (maston28)
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

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é

Poste le Tuesday 25 April 2006 09:36:26

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...)

Poste le Tuesday 25 April 2006 09:44:41

Citation
Kynes
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é

-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 .

Poste le Tuesday 25 April 2006 12:38:01

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

C'est cassé le DES ?

Poste le Tuesday 25 April 2006 16:10:09

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.

Poste le Tuesday 25 April 2006 16:21:56

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.

Poste le Tuesday 25 April 2006 17:50:59

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é.

Poste le Tuesday 25 April 2006 20:22:54

Citation
Léa (maston28)
bonjour tout le monde, ca fait plaisir de revenir ici ca faisait longtemps

... oui !
Bon retour, alors ^o^.

[catwell.info]

Poste le Friday 28 April 2006 20:14:01