[Kamil DuCiel]

Hey tout le monde ! Aujourd'hui j'ai eu cours d'info a polytechnique ,et on a notamment parler de fréquence d'un processeur et des fonctions de hachage. ( MD5 et SHA-1)

J'ai énormément de mal a comprendre pourquoi ces fonctions la sont dites " inviolable" du faites dutemps que prendrai le cassage en brute forcing de la clée . On a aujourd'hui des processeur qui font , si j'ai tout compris 2milliard d'opération/seconde!

Je comprend bien que casser des clée de 2048 bits pour du RSA , c'est long , mais en se penchant plus prés , ( si j'ai tout compris, aprés je peut me planter) pour le RSA , on cherche a factoriser un nombre x qui a environ 600 chiffres par deux entier P et Q qui sont plus ou moins voisins en terme de taille et premier. Pour cela, ils nous faut tester donc tout les entiers premier entre 0 et racine de x. De plus , P et Q sont de taille voisines , donc tout les premier entre 0 et y , ou y un nombre de 250 chiffres sont a exclure. J'ai donc du mal a comprendre pourquoi les ordinateurs actuellent "rame" tellement sur ce genre de brute forcing

Pour les algorithme de hachage, sa reste aussi pour moi trés obscure. J'ai du mal a comprendre le concept des rainbow-table. J'ai compris qu'on se servait de ces table pour dire a l'ordi " hey regarde donc la dedans si le code y serait pas déja " mais j'ai du mal a comprendre pourquoi ces tables serait une "économie de place" par rapport a la méthode qui consiste a stocker toute les **orthographe !** et leurs MD5.


Merci pour vous future réponse

[ferbos]

En ce qui concerne la factorisation des grands nombres, j'ai lu que la meilleure technique reste l'algorithme NFS (techniques de hacking - Jon Erickson) par son temps d'exécution sous-exponentiel. Elle reste insuffisante pour une résolution dans un temps raisonnable sur 2048 bits. Il ne reste plus qu'à tester ou à calculer le nombre d'opérations sur une clé de ce type. Qu'en penses-tu?

Petit aparté: ce n'est pas une clé RSA de 2048 bits qui va empêcher le NSA de nous espionner d'un peu trop près à mon goût.

ferbos

[MistBlood]

Salut, pour ce qui est de stocker tout les mots de passes possibles et leur md5 associés, si on part sur des mots de passe de longueur 8, on a comme quantité de data (on considère 72 chr utilisable pour composer ces passwd) :

8^72 possibilité * 8 bytes (psswd)
+ 8^72 * 16 bytes (md5 associé)

(8^73 + 8⁷² * 16 ) /(2^(80)) = 20 x 10^42

donc on a pour les mots de passe de longueur 8 chr (tiré d'un pool de 72 chr) et leurs md5 : 2090694862362245919518973588060783891185664 Yo.

Si je ne me trompe pas dans les calculs, évidement.

rien que pour les mots de passe de 8 ! On parlera pas des truc du genre "jaimeroulerenvoiture" ... Soyons raisonnable

L'idée des Rainbow Table, c'est de lister tout les mots de passe courant (on commence par admin, on rajoute les prénoms, les date de naissance commençant en 1900, ...) et de calculer les hasch MD5 associé. On a donc sous forme de double liste des md5 associé à des mots de passe courants.

Malheureusement, bien souvent, les mots de passe utilisé par le commun des mortel sont courants. Donc, les Rainbow Tables ont un certain sucés ! Quand tu arrive à obtenir un digest-hasch d'un passwd (haché, donc), tu peut vite vérifier si le digest-hasch ne correspond pas à une entrée de la rainbow table, un mot de passe bidon, genre admin, root, adminroot, adminrootremiadminderrière, ... enfin bref, tu comprends.

Du coup, comme tu as eu un coup sur les fonction de hachage, et ou on a parler des Rainbow Table, on a du aussi présenter les fonctions de salage (je ne vois pas trop comment dire en français), qui rendent les hachages plus sur en les épicants un peu. C'est là que ça devient intéressant. Si on ne t'en a pas parlé, alors, c'est que ça sera pour le prochain cour. Si on ne t'en parle pas, alors franchement, renseigne toi à ce sujet. Faudrait pas ratter cette idée toute simple qui consiste à épicer le mdp avant de le hacher (ça fait un peu cuisine, non ?)!


MistBlood

[_o_]

les fonctions de salage (je ne vois pas trop comment dire en français),

On parle de sel, ou d'empreinte salée. Je n'ai jamais entendu parler de fonctions, par contre, puisqu'il s'agit juste d'une concaténation.

[MistBlood]

On parle de sel, ou d'empreinte salée. Je n'ai jamais entendu parler de fonctions, par contre, puisqu'il s'agit juste d'une concaténation

Effectivement, je parle comme un albran. Je voulais plutôt dire que les fonctions de hachage acceptent bien souvant un paramètre "Sel".

Par exemple :
crypt ( string $str [, string $salt ] ) en PHP, ... Qui fait la concaténation et le hashage en suite.

Voilà, comme ça c'est plus clair, et il y a un exemple. Merci pour la relecture _o_.


MistBlood

[the lsd]

L'idée des Rainbow Table, c'est de lister tout les mots de passe courant (on commence par admin, on rajoute les prénoms, les date de naissance commençant en 1900, ...) et de calculer les hasch MD5 associé. On a donc sous forme de double liste des md5 associé à des mots de passe courants.

Euhhh, pas du tout ? Les Rainbow tables, ca n'est pas un simple listing des mots courants. C'est une solution pour essayer d'avoir un compromis entre bruteforce (très long) et dictionnaire (très gros). C'est un principe de hash/réduction qui permet de stocker uniquement le minimum requis : plus d'infos ici, c'est plutôt bien expliqué imho

Ce dont tu parles, pour moi, ressemble plus aux bases de données <insert you hash type here>breaker.

Enjoy

The lsd

[shanks]

Pour se convaincre de l'inutilité du brute-force totalement naïf sur RSA, voici un rapide calcul du temps que cela prendrait pour trouver P et Q. Prenons une clé de 512 bits et reprenons tes hypothèses:
- Je sais que P et Q sont de tailles 256 bits (et sont donc "proches").
- Je suis capable de faire 20 milliards d'opérations par seconde.
- Je vais même plus loin, je sais tester que P divise N en une opération -> je peux donc tester 20 milliards de premiers par seconde.

Estimation du nombre de premier de taille 256 bits (en calculant x/ln(x)): (2^256)/ln(2^256) - (2^255)/ln(2^255) = 3.2500e+074

Estimation du nombre de secondes nécessaires: t = 3.2500e+074 / 20e+09 = 1.6250e+064 s

Ce qui nous donne en année: t = 1.6250e+064 / (3600*24*365) = 5.1528e+056 ans

Je préfère autant lancer un puzzle de 10000 pièces et espérer qu'il se fasse tout seul en retombant, c'est plus probable

[the lsd]

Je préfère autant lancer un puzzle de 10000 pièces et espérer qu'il se fasse tout seul en retombant, c'est plus probable

XPLDR, je l'avais jamais entendue celle là

Enjoy

The lsd