Annonce

**TorTukiTu** · 30 juillet 2013, 11h12

hach MD5 mais pas seulement de simple hach, le programme permettras en plus de sa de pouvoir préciser une éventuelle clé de cryptage

Tu veux faire du steak haché ?

Sinon, je n'ai rien pigé à ton post.

Tortue 974.

**2ShEp** · 30 juillet 2013, 13h15

Déjà à l'apéro Tortue

Le MD5 n'étant pas un algo de cryptage à clé mais une empreinte numérique, j'imagine que quand tu parles de clé de cryptage, tu veux du dire un sel (salt) !?

Après pour stocker tes dicos l'important va être les temps d'accès donc je penses qu'avec un bon SGBD comme PostGreSQL ça sera pas mal. Ta table doit être le plus simple possible.
#HASH(passphrase,hash);

Pour l'algorithme de brute force, tu parles de doublons mais les cas de collision qui ont été démontrés sur MD5 ne sont que très{10} rare.

Je ne vois pas trop l'utilité d'une GUI.

Après, il existe déjà une pléthore d'outils très bien fait donc il faut trouver un moyen de faire sortir le tien du lot.

Quelques idée comme ça, sans trop réfléchir :

Idée0 : Faire tes test d’égalité bits à bits plutôt que sur le hash complet.

Idée1 : Le point le plus important d'un BF est sa rapidité d'exécution donc pourquoi ne pas coder les points critiques en ASM.

++
2ShEp

**TorTukiTu** · 30 juillet 2013, 13h59

Peut être utiliser tes GPU ?

Tortue 974.

**LordZerty** · 30 juillet 2013, 14h14

Salut 2ShEp et merci pour ton aide.

En effet, quand je parle de clé, je parle du SALT, je ne connaissais pas le terme exacte.

En ce qui concerne le stockage des dicos, je pensé me servir directement de fichier texte, mais il est vraie qu'après certains tests, c'est long... Je me servirais donc de PostGreSQL. Au niveau de la table je pensé en faire une très simple :
-----------------------------------------------------
|ID | Chaîne_Txt | -------------HASH ---------------|
|----------------|-----------------------------------
|1 | alexandre ---|1ff08ee2c97fa5efc2080da444e3db9f|
|2 | france ------|1ff08ee2c97fa5efc2080da444e3db9f|
|3 | pays--------|1ff08ee2c97fa5efc2080da444e3db9f|
|4 | sardine------|1ff08ee2c97fa5efc2080da444e3db9f|
|5 | arbre -------|1ff08ee2c97fa5efc2080da444e3db9f|
-----------------------------------------------------

Il vaut mieux répartir les chaîne sur plusieurs tables ou dans une seule grosse tab.

oki, pour les doublons.

Euh un GUI c'est jolie ? Tu pense que sa peut ralentir le programme ?

Merci pour tes conseils et idées, j'en prendrais compte lors du développement.

Peut être utiliser tes GPU ?

Oui, pourquoi pas, j'ai vue que sa amélioré grandement la vitesse, je vais voir comment sa fonctionne.

**2ShEp** · 30 juillet 2013, 14h15

Autre idée : Mettre au point un système de distribution des calculs entre plusieurs machines.

EDIT0 : C'est largement suffisant comme table.

Envoyé par LordZerty

Il vaut mieux répartir les chaîne sur plusieurs tables ou dans une seule grosse tab.

Aucune idée, je ne suis pas expert de BDD, peut être que Tortukitu saurait te répondre...

La GUI c'est jolie mais pas très utile en tout cas dans un premier temps. Ralentir non sauf si tu affiche des choses à chaque tour de boucle (genre : "pas de correspondance trouvée").

**TorTukiTu** · 30 juillet 2013, 16h40

Il faudrait un DBA pour t'expliquer tout ca dans le détail. Je n'ai pas les connaissances nécéssaires pour t'expliquer en profondeur... DBA, c'est un métier à lui tout seul...

Quand tu éclates sur plusieurs tables, c'est typiquement pour faire du relationnel.

Si tu n'as qu'un type de relation clé / valeur, éclater en plusieurs tables n'a aucun intéret.

Pire, avec PostGres, tu vas embarquer un SGBD relationnel très lourd dont tu n'utilisera qu'un petit 0.001% de ses fonctionnalitées.

Je te conseille d'aller fureter du côté des nosql. C'est à voir, mais, par exemple, si tu as moyen d'utiliser convenablement un Kyoto Cabinet, tu auras moyen d'avoir des perfs terrifiantes.

Kyoto Cabinet runs very fast. For example, elapsed time to store one million records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree database.

Tortue 974.

**LordZerty** · 30 juillet 2013, 19h58

MMMMhh d'accord merci pour vos suggestions et votre aide.

**2ShEp** · 31 juillet 2013, 08h01

Bien vu Tortue, c'est sur qu'utiliser PostGre pour faire des requête de sélection basique c'est pas la meilleur idée que j'ai eu

Je ne connaissais pas Kyoto Cabinet (connais pas bien NoSQL non plus), merci pour la découverte. Les perfs ont l'air monstrueuses !

Si je comprends bien le principe, ont stock uniquement des associations clé/valeur donc la modélisation ressemblerait à ça :
#TBL0(id,hash)
#TBL1(id,passphrase)

On tape sur la TBL0 pour chercher le hash et ensuite si il est trouvé ont récupère la correspondance de l'id dans la TBL1 pour connaitre la passphrase associée ?

++
2ShEp

**fred** · 31 juillet 2013, 15h33

Idée1 : Le point le plus important d'un BF est sa rapidité d'exécution donc pourquoi ne pas coder les points critiques en ASM.

Le compilateur permet d'optimiser un code en transformant le code C en assembleur... Pourquoi faire compliquer ?

Pour l'algorithme de brute force, tu parles de doublons mais les cas de collision qui ont été démontrés sur MD5 ne sont que très{10} rare.

Alors pourquoi ne l'utilises-t-on plus ?

Actuellement, j'ai d'énormes dictionnaires à ma dispositions, j'ai en premier lieu tenté mon projet via du PHP mais ce langage n'étant pas adapter, j'ai choisi de le faire en C/C++

Ce qui m'intéresse c'est pas le langage utilisé, mais l'algorithme utilisé pour faire ce genre de chose.
Qui puis-est avec un algorithme on comprendrait beaucoup mieux ce que tu souhaites faire.

Désolé, mais les projets, sans algorithme ou déroulement permettant de résoudre, c'est pas un projet

**2ShEp** · 01 août 2013, 07h17

Le compilateur permet d'optimiser un code en transformant le code C en assembleur... Pourquoi faire compliquer ?

Parce que c'est formateur et pas si compliquer !

Alors pourquoi ne l'utilises-t-on plus ?

Il existe des bases de hash tellement énormes qu'il devient peux sûr, surtout si il est non salé ou que l'attaquant à réussi à le récupérer. (je met SHA-1 dans le même sac)

Ce qui m'intéresse c'est pas le langage utilisé, mais l'algorithme utilisé pour faire ce genre de chose.
Qui puis-est avec un algorithme on comprendrait beaucoup mieux ce que tu souhaites faire.

Désolé, mais les projets, sans algorithme ou déroulement permettant de résoudre, c'est pas un projet

Pressé ? Laisse lui le temps de choisir ses solutions et de se renseigner ! C'est la pire chose à faire que de se lancer dans un projet sans étude préalable.

**fred** · 01 août 2013, 09h24

Parce que c'est formateur et pas si compliquer !

Ah! Donc le C n'est pas formateur ?

Pressé ? Laisse lui le temps de choisir ses solutions et de se renseigner ! C'est la pire chose à faire que de se lancer dans un projet sans étude préalable.

Il me semblait qu'il l'avait déjà fait en PHP...

**2ShEp** · 01 août 2013, 09h59

Ah! Donc le C n'est pas formateur ?

Où j'ai dis ça ? Tu déformes complètement, c'est limite de la mauvaise foie

Il me semblait qu'il l'avait déjà fait en PHP...

Plus au moins, c'était plutôt un rassemblement d'idées et un changement de solution(langage) en cours de route mérite un temps d'arrêt pour réfléchir, chercher les API qui vont bien, etc...

Tu sort vite les crocs toi

++
2ShEp

**mactux** · 01 août 2013, 10h04

Tu sort vite les crocs toi

T'as vu l'avatar aussi...

**TorTukiTu** · 01 août 2013, 11h21

Juste une petite remarque,

Il existe des bases de hash tellement énormes qu'il devient peux sûr, surtout si il est non salé ou que l'attaquant à réussi à le récupérer. (je met SHA-1 dans le même sac)

Certes, mais tu as des immenses DB pour n'importe quel algo de hachage. Il me semble que MD5 n'est plus concidéré comme sur depuis que des chercheurs chinois sont parvenus à déterminer des collisions avec un hash quelconque (dans des conditions très particulières).

Sinon, je suis grossièrement d'accord avec 2ShEp. Ecrire les portions critiques en ASM te fera gagner un peu en vitesse (et te permettra d'apprendre beaucoup de choses !).
Par contre, limite toi aux petites portions.

Le code machine compilé sera probablement plus efficace que le tien sur de larges portions de code.

Désolé, mais les projets, sans algorithme ou déroulement permettant de résoudre, c'est pas un projet

fred, tout dépend où tu en es dans ton projet.

Les algos font partie de la grannularité la plus fine dans la gestion de projet.

projet c'est avant tout (plus ou moins dans l'ordre) :
- un cahier des charges,
- de l'architecture,
- des specs,
- du design <= Tes algos sont déterminés ici en fonction de ce qui précède,
- puis du code (et des tests).
- de l'optimisation (et des tests)

Par contre, LordZerty, ce serait bien d'avoir tes specifications, ou à défaut un cahier des charges.

Tortue 974.

Annonce

Brute-Force MD5 avancée

Brute-Force MD5 avancée

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire