UN KEYGEN EN LOSING BYTE UNE ALTERNATIVE A MD5
japee
Messages postés
1727
Date d'inscription
vendredi 27 décembre 2002
Statut
Modérateur
Dernière intervention
6 novembre 2021
-
25 nov. 2003 à 16:40
cs_ManChesTer Messages postés 374 Date d'inscription vendredi 20 octobre 2000 Statut Modérateur Dernière intervention 15 janvier 2021 - 9 sept. 2009 à 20:43
cs_ManChesTer Messages postés 374 Date d'inscription vendredi 20 octobre 2000 Statut Modérateur Dernière intervention 15 janvier 2021 - 9 sept. 2009 à 20:43
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/18207-un-keygen-en-losing-byte-une-alternative-a-md5
https://codes-sources.commentcamarche.net/source/18207-un-keygen-en-losing-byte-une-alternative-a-md5
9 sept. 2009 à 20:43
pou md5 :va lire http://www.win.tue.nl/hashclash/rogue-ca/
Quand au mot de passe, non il n'est pas long, mais si tu essaye la meme technique que pour le hash tu a baucoups de chance de passer a coté ;)
Pour le 2eme messages, pour la compréhension didactique je comptele laisser en string et meme pas le rendre aussi secure que ce que je pourrais. En faite je veux que les développeurs me contacte pour utiliser cet algo de facon sécure. De cette facon, je sais ou et par qui il est utilisé ;)
Bon Coding...
ManChesTer.
9 sept. 2009 à 13:13
Ah je vois. Tu voudrais dire trouver une valeur pour laquelle H(X) = 'm1db...'. Evidemment, c'est plus dur. Mais je ne suis pas d'accord quand tu dis qu'une collision md5 par exemple est facile à obtenir. Il y a quand même 2^64 hashs à garder en mémoire, et on a seulement 1 chance sur 2 ...
Mais le truc c'est que j'ai pas trop le temps de trouver le mdp. En fait, je m'en fiche un peu, j'ai fait ce que je voulais (attaquer ton algorithme en tant que fonction de hachage). Mais si ça peut te faire plaisir, je peux m'y mettre si tu me demande (à condition que tu me jures que le mot de passe ne soit pas trop long ... sinon ça n'a plus aucun sens).
2eme message
lol ok. Une bonne idée pour le rendre utilisable serait de le faire fonctionner non plus en "string", mais bien en "buffers". Tu transmets un pointeur et une taille. C'est portable, simple à utiliser et souple.
Cordialement, Bacterius !
9 sept. 2009 à 13:06
Un point que tu m'a fais remarquer c'est que il est vrai que les keygens onts évoués (celui-ci date de 1989 ce qui est une éternité dans l'informatique, 20 ans, lol).
Je vais donc poster sous peux une V2 (des que j'ai le temps) basée sur la meme technique juste avec quelques ajouts afin de le rendre utilisables "tel quel" par un développeur.
Cependant je ne le rendrai pas révolutionaire ou inviolable nonplu, le but reseras pédagogique.
Pour plus de sécurité les utilisateurs qui veulent inclure cette technique peuvent me contacter le mail est dans le source dans ce but principalement.
Cette fois ci, pour te faire plaisir, je ne mettrai pas que c'est une alternative a md5, comme ca on seras tous contents, lol.
Bon Coding...
ManChesTer.
9 sept. 2009 à 12:43
Non on ne s'est pas compris, une collision qui donnrais bravo vous avez trouvé le pass, lol
Les collisionde hash, facile a trouvé, je t'ai meme expliqué comment résoudre le probleme (l'ajout d'un xor, tu te souviens).
Ce q'il faut trouver est un pass ou un collusif qui va me donner le makeKey4d(x)='m1db-OcTg-yI2i-2wih'il faut trouver un x qui donne le bon resultat.
Bon Coding...
ManChesTer.
9 sept. 2009 à 09:06
[“óØMÒËã‚tUä] [ÿóòÜä%teŒä] [03A8-AcrK-GToA-fO9s]
[$z䧗;»JV#] [i@#Ž.±¶,\ó#] [02jw-vWC0-Ez0C-2dMg]
/‹ÝFˆÈâÐßcž¢ [‘íß_ÖVšÞmí¢] [03A8-AcrK-48Bu-Eua4]
J'en obtient une bonne poignée (+ ou - 300) toutes les 2^16 opérations.
Cordialement, Bacterius !
9 sept. 2009 à 08:17
Cordialement, Bacterius !
9 sept. 2009 à 08:15
Cordialement, Bacterius !
9 sept. 2009 à 08:12
Mais non voyons d'apres tes propres dires, tu va trouvé un "compatible" bien avant puisque, je te cite :
"Ton algo n'est donc pas résistant aux collisions sur une base de 2^64 comme prévu, mais 2^32, ce qui est très peu (en deux nuits avec un bon PC, c'est clos)."
Donc dans 4 nuits (on va supposé que tu n'a pa un bon pc), c'est clos. (Note c possible si tu a beaucoups de bol et un bon pc).
Dapres d'autres cryptanalystes qui onts analysé cet algo eux m'assurent pourtant que tu a 1 chance sur (n ln x+13) exp 32 mais prouve qu'il se trompe ca serais un bel exercice. En plus, ca me ferais bien rire sachant d'ou me viens cette cryptanalyse.
Bon Coding...
ManChesTer.
9 sept. 2009 à 06:24
Effectivement, changer trois mots dans ton algo réparerait la faille. Mais TEL-QUEL, alors la complexité du brute-force est divisée par un facteur de 2^32 (ou 2^64 sans stockage mémoire).
Mais bon, puisqu'il te faut un exemple concret, je vais te trouver ton pass (mais il faut que tu me garantisse que ton mot de passe soit inférieur à 20 caractères ... sinon les limites matérielles rappellent vite la logique à l'ordre).
Ah en passant ton mot de passe est *mince je l'ai pas encore trouvé ça aurait été trop stylé lol*.
Cordialement, Bacterius !
8 sept. 2009 à 21:12
a oui j'oubliais ce que j'ai ecrit plus haut :
"A ta place je réviserais le
"Pour "12", les deux premières parties sont les mêmes que avec "21". Même chose avec "AB", et "BA", et toutes les chaînes mélangées en général ("abc", "cab", "bca", "acb") ... ???"
qui ne tiend pas compte de la perte de données..
Donc, trouve le pass, on en repale aprés, lol"
reste valide et commetu basse ton cassage la dessus, hemmm, lol
Bon Coding...
ManChesTer.
8 sept. 2009 à 20:57
Reflechis 2 secondesregarde lalgo et imagine l'endroit ou tu pourrais rajouté un simple xor, et ce que tu apelle une faille cumulative n'existe plu...
Pour moi ce n'est nullement une faille, mais c'est parce que on ne considére pas l'algo dansle meme sens ;), Le but du post de cet algo est simplement de montré que il y a d'autres techniques que md5 ou que les hash connus.
En attendant puisque tu est sur de toi va sjusque au bout donne moi un pess ou un collusif qui va me donner le (makeKey4d(x)='m1db-OcTg-yI2i-2wih') resultat (x), je l'attend toujours, lol, la théorie est une chose, la completer parfois, une autre.
Bon Coding...
ManChesTer.
8 sept. 2009 à 08:34
Cordialement, Bacterius !
8 sept. 2009 à 08:32
Cordialement, Bacterius !
8 sept. 2009 à 08:15
Non, juste losing byte,
C'est un morceau d'algo que j'avais ecrit a l'époque de l'atari ST. Il etais destinné a vérifier des mot depasse pour des fichiers compresés (comme le pass des zip). Et aussi de veifier l'intégrité du fichier en lui meme.
Bien que pour le hash il n'est pas parfait, pour stocker des pass, il est cool.
Il est actuellement complexifié et utilisé dans certaines applications professionelles que développe une scociété spécialisée en securité informatique.
Bien entendu je n'ai ici poster que la base la version de travail (le premier "jet" en version 0.0.0.1) qui représente a mes yeux plus l'idée générale qui va permettre, apres compréhention de l'algo, et personalisation et/ou modification de proteger par exemple les sn de son sharware ou de verifier des mot de passes pour une application etc..
Certains auteurs de sharware frewares et meme d'autres utilisent une variante de cet algo et sonts en contacts avec moi conformément au texte qui est inscrit dans le source. Dans tous ces cas nous avons adaptés l'algo.
Bon Coding...
ManChesTer.
8 sept. 2009 à 08:04
Mais une fois que tu auras lu la cryptanalyse, tu seras bien d'accord avec moi que ton mot de passe sera simple à récupérer, et ce en deux étapes :
1) Tester plusieurs ensembles d'octets, sans aucune permutation (comme "abc", "bcd", "cde", ... mais jamais "abc" puis "bac"), jusqu'à ce que l'on trouve que les 64 premiers bits du hachage = "m1dbOcTg".
2) Tester toutes les permutations de l'ensemble obtenu précédemment, jusqu'à obtenir la permutation pour laquelle les 64 derniers bits du hachage = "yI2i2wih". Cette donnée sera alors le mot de passe, puisqu'elle aura le hachage "m1db-OcTg-yI2i-2wih". Enfin ... ce ne sera peut-être pas LE mot de passe que tu espérais, si le nombre de collisions est plus élevé que je ne pensais, mais j'aurai répondu à la question : "trouve une donnée qui correspond à ce hachage". L'existence de collisions implique qu'il est impossible de répondre à la question "trouve LA donnée qui correspond à ce hachage.", puisqu'il en existe une infinité.
Cordialement, Bacterius !
8 sept. 2009 à 07:52
Voici le lien pour la cryptanalyse (en PDF). Lis bien tout, surtout les mots en gras (et encore plus les mots en gras soulignés). Bonne lecture !
http://www.freefilehost.co.uk/260386 (mot de passe : "delphifr" sans les guillemets).
Cordialement, Bacterius !
8 sept. 2009 à 06:38
En fait, il faut prendre une chaîne de caractères de longueur N, avec N! >2^32 (soit N 13). La factorielle de N nous donne alors le nombre de possibilités de combinaisons en utilisant un ensemble restreint (comme [a, b, c], mais de longueur N).
Il a un nom ton algorithme ?
Cordialement, Bacterius !
8 sept. 2009 à 05:55
Là je ne te parle pas du mot de passe, mais plutôt de l'affirmation "une alternative à MD5".
Essaye de récupérer le keygen de "ABC", "CAB", "BCA", ... les deux premières parties sont les mêmes !
Je ne m'intéresse encore une fois pas à la perte de données, mais au fait que cet algorithme n'est pas une alternative à MD5 (comparons ce qui est comparable : MD5 = Fonction de hashage, donc je suppose que tu considères ton algo comme une fonction de hashage. Ces dernières doivent être résistantes aux collisions, c'est-à-dire qu'il doit être impossible de trouver une collision sans un certain nombre d'opérations. Ce nombre d'opérations définit la résistance de l'algorithme).
Mais on ne pourra jamais se mettre d'accord via des commentaires.
Donc ... je rédige tout ça et je te l'envoie par mail, si tu veux me la passer par MP (je crois l'avoir aperçue quelque part mais je ne sais plus où ... m*n***st*r@skynet.be ?
Cordialement, Bacterius !
7 sept. 2009 à 13:13
Je vais jute te répondre une chose,tu est bien sur de toi, lol
A ta place je réviserais le
"Pour "12", les deux premières parties sont les mêmes que avec "21". Même chose avec "AB", et "BA", et toutes les chaînes mélangées en général ("abc", "cab", "bca", "acb") ... ???"
qui ne tiend pas compte de la perte de données..
Donc, trouve le pass, on en repale aprés, lol
Bon Coding...
ManChesTer.
7 sept. 2009 à 09:57
il suffit de prendre une chaîne de caractères de longueur 4 (ça fait donc 255^4 = 2^32 combinaisons de bits possibles).
on teste toutes les permutations de la chaîne (par exemple, "abcd", "dcab", "bcda", ...)
le résultat final de ton algo est sur 16 caractères, ce qui fait 255^16 2^128 combinaisons possibles. Or, d'après la propriété que j'ai énoncé ci-dessus, pour les permutations de notre chaîne, les deux premières parties restent identiques. Le nombre de combinaisons est donc réduit à 2^64. Or, d'après le paradoxe des anniversaires, il faut Sqrt(2^64) 2^32 essais pour avoir 1/2 de chance de trouver une collision. Ton algo n'est donc pas résistant aux collisions sur une base de 2^64 comme prévu, mais 2^32, ce qui est très peu (en deux nuits avec un bon PC, c'est clos).
Bref, pour clore le débat qui fait rage depuis 3 ans, ce n'est ABSOLUMENT PAS une alternative à MD5 (c'est plus lent que MD5, d'ailleurs ...), sachant que MD5, n'offre plus sa sécurité théorique aux collisions de 2^64, mais un peu moins de 2^57, ce qui reste cependant bien suffisant (seules les puissantes organisations ont le temps, l'argent, et la raison d'effectuer un tel nombre d'opérations).
Bon sinon, pour ton mot de passe, j'ai aussi la flemme de coder le brute-force, je le ferai un de ces jours.
Cordialement, Bacterius !
7 sept. 2009 à 08:54
Il doit exister une fonction algébrique pour savoir de combien de % on améliore les performances, mais j'ai la flemme de chercher maintenant. Je commence le brute-force pour récupérer ton mdp.
Cordialement, Bacterius !
7 sept. 2009 à 07:47
Première étape - approche générale :
Pour "12", les deux premières parties sont les mêmes que avec "21". Même chose avec "AB", et "BA", et toutes les chaînes mélangées en général ("abc", "cab", "bca", "acb") ... ???
On verra pour la suite ;o
Cordialement, Bacterius !
3 oct. 2008 à 11:35
28 juil. 2005 à 12:55
Le source ce n'est pas une inforation ?
Moi, il me semble que c'est la plus importante, pour moi, le coder qui ne pige pas cet algo, n'est pas capable de le maitrisé et donc ne doit pas jouer avec.
D'autre part, j'ai pondu cet algo en 1989 et cette technique et ses dérivée est utilisée depuis 1992 par une sociètè spècialisèe en sècuritè informatique, jusque ici, aucun de leurs clients ne s'est plaint d'une quelconque infiabilité de cette routine.
La seule chose que j'ai changé à mon algo, c'est juste de le traduire de l'assembleur en delphi et de passer du 16bits au 32bits.
Mais bon, pour le tester , tu a le source, tu à un pass à retrouvé ('m1db-OcTg-yI2i-2wih'), fais le (en C++ c'est mieux, mptdr)!
D'autre part, je ne suis pas le seul a dire que md5 est Hackable et hacké, si tu avais pris la peine de lire le forum dont je donne l'adresse si dessus tu le saurais, mais peut etre ne comprenons nous pas le meme anglais ?, pourtant l'exemple des tables est frappant et permet de reduire le nombre de "tests" en bruteforce, ce qui rend justement md5 infaible pour les mot de passe...
Bon Coding....
ManChesTer
28 juil. 2005 à 09:31
Ah ben, t'es bien le premier à affirmer une telle chose. Alors merci d'abandonner les "évidences"... Beaucoup pensent qu'il est solide (dont moi), et de toute façon, pour créer des sites Web dynamiques, c'est satisfaisant, suffisant et on ne se pose pas de questions. Il "paraîtrait" qu'on a juste l'obligation de masquer les mots de passe dans les bases de données MySQL de manière à ne pas pouvoir retrouver l'original. Ce masque tombe d'ailleurs sous le sens...
Et j'en rien à faire vos histoires de md5. Je demandais simplement pourquoi (et comment) on peut-être sûr que ton code soit fiable ? Je ne doute pas des capacités Manchester (alors merci de ne pas croire des choses que j'ai pas dites, notamment "con", "idiot" et autres) : c'est vrai que le code est séduisant (diversité des lettres, longueur...), mais techniquement, comme pour le MD5 (d'après tes propos), il faut le tester. Et c'est là qu'il faut de l'information...
27 juil. 2005 à 19:44
Depuis quand les clef de win xp par exemple sont en hexa, t'a jamais enregisté ton xp ?
Bon Coding...
ManChesTer.
27 juil. 2005 à 19:39
Puisque la sécurité d'un algo viens de sa complexité, et de sa documentation (enfin c'est ce que tu dit), tu vas sans peine nous retrouver le mot de passe qui correspond à la clé 'm1db-OcTg-yI2i-2wih' comme je le propose dans le code et comme tu le propose si bien dans ta phrase "un bruteforce C++ pulvériserait des records de vitesse au niveau de la tentative de décodage" bien que je n'ai pas compris pour quoi en c++ et pas en Asm, m'enfin c'est que je dois etre con.
Il faut savoir que md5 est craké depuis quelques temps, mais ca tu le savais déja en grand pro du sujet, evidament...
voir sur ton forumpréféré :
http://www.governmentsecurity.org/forum/index.php?showtopic=10777
Je ne préténd pas que se code est plus inviolable que md5 mais, que comme tous le monde utilise md5 pour le stockage de mot de passe, il me semblais interessant pour la sécurité de publier une mèthode aussi fiable, bien plus simple, et surtout modifiable et compréhensible par tout programmeur un peux "intelligent", qui si il le désire peut facilement ajouter les xor &co bien que je n'en vois pas l'utilité.
La raison pour laquelle l'algo proposé ici est sécure est simplement du au fait que la clef ne reflete pas le mot de passe, on perd des infos au passage d'ou le "losing bytes", donc retrouver le pass depuis la clef est vraiment hard. Enfin on attend quand meme ta solution.
Bon Coding....
ManChesTer.
27 juil. 2005 à 15:51
grandvizir: "Titre du code> "Alternative au MD5" Ben, à quoi sert SHA1 alors ?"
ManChesTer: "Le titre ne mensionne pas "LA SEULE Alternative au MD5" Si ?"
grandvizir: "Je suis d'accord que ce n'est pas LA SEULE alternative. D'ailleurs, j'ai pas dit ça."
Je suis au bord d'un abîme de perplexité...
Sûr que le jour où je comprendrai ta logique, Grandvizir, j'aurai fait un grand pas en avant, mdr! ;)
___japee_ ->
|
|
|
|
|
|
|
|?????????????????
27 juil. 2005 à 12:18
Le MD5 est très documenté et il n'a pas de problèmes. Mais vu la petitesse du script comparé à MD5, je vois mal comment tu peux espérer qu'il soit inviolable. Mais surtout, un bruteforce C++ pulvériserait des records de vitesse au niveau de la tentative de décodage.
Où sont les SHR, le SHL, les XOR... dans ton code ? Pour du "losing byte", c'est un peu léger.
Autre regret: les clés sont généralement des sérials en hexadécimal.
Au final, ton code pourra toujours aider à la création de clés, mais en aucun cas, je ne vois d'alternative. Peut-être que je me trompe, mais tant qu'il n'y a pas de documentation, ça sent la fébrilité (même si la longueur de la clé est déjà conséquente).
;)
25 juil. 2005 à 21:59
Le titre ne mensionne pas "LA SEULE Alternative au MD5" Si ?
Il est en fait une alternative à tous ce qui est stockage de mot de passes, comme on perd des infos au passage, bon courrage pour le reverse, seule solution viable pour le Hacké : Le bruteforce (comme MD5 quoi que...).
Qand à SHA1, heuu ...Il est plutot fait pour faire des signature de fichiers, et n'a rien a voir avec MD5 ou mon algo. Attention, ne pas utiliser SHA1 pour stocker des mots de passe, il n'a pas été fait pour, il est tres facile de retrouver un "Compatible password", et donc il est assez peux fiable por le stockage/verification de mot de passe. D'un autre Côtè, MD5 ou mon algo n'ont pas la vocation de servir pour les signature, meme si on peut le faire avec....
Bon Coding....
MnChesTer.
25 juil. 2005 à 14:38
Ben, à quoi sert SHA1 alors ?
http://www.codes-sources.com/rfc.aspx?rfc=3174
2 déc. 2003 à 16:21
Tu a raison la val correcte est 62, je le savais, mais je n'ai pas mis a jour la version sur le site....
Je prepare un ptit truc pour les fetes qui utilise le keygen, j'avais remarquer le bug a cette occase..., je le met a jour, lol
Bon Coding...
ManChesTer.
2 déc. 2003 à 15:22
Pas trop la forme en ce moment... ;)
2 déc. 2003 à 15:15
Ce code est particulièrement intéressant.
Précisément, en travaillant dessus comme une bête, j'ai découvert un léger bug, qui peut s'avérer éventuellement gênant, selon comment on va exploiter la clé générée...
Dans les instructions :
i:=round(a) mod 61;
i:=round(b) mod 63; etc...
il semblerait que la valeur correcte soit 62, soit :
i:=round(a) mod 62;
En effet, avec 61 on n'a jamais de 'z' (Chr(122)), et à partir de 63 (le cas se produit), 'i' n'est pas traité (donc il va manquer un caractère) dans ce type d'instructions :
case i of
0..9 : p1:=p1+chr(i+48);
10..35: p1:=p1+chr(i+55);
36..61: p1:=p1+chr(i+61);
// else ShowMessage('Dépassement de limite');
end;
Tu peux le tester, par exemple :
- sans changer la valeur dans a:=a*100
nom: tot
clé: LG0e-Etx-IhiU-E14g (3 caractères seulement dans la 2ème série)
- en remplaçant la valeur 100 par :
- 109 :
toto
bKXv-BmA-nw1A-ppWp (3 caractères dans la 2ème série)
- 110 :
toto
A7v6-30hG-WCpX-sTQ (3 caractères dans la 4ème série)
- 106 :
ManChersTer
W2gp-yX5n-lG8Q-hNV (3 caractères dans la 4ème série)
etc...
Merci encore pour ce code. Vraiment utile !
Bonne prog' ;)
25 nov. 2003 à 22:05
25 nov. 2003 à 21:26
Bon Coding...
ManChesTer.
25 nov. 2003 à 18:46
Chez moi le ZIP contient des CLASS JAVA....lol
25 nov. 2003 à 17:06
correction effectuèe...
Bon courrage pour trouvé le pass qui correspond a 'm1db-OcTg-yI2i-2wih', des bytes s'etant "volatilisèe" au passage, il faut un bruteforce, lol.
Bon Coding...
ManChesTer.
25 nov. 2003 à 16:51
C'est à nous de créer notre clé, et éventuellement retrouver le mot de passe qui correspond à la clé 'm1db-OcTg-yI2i-2wih'.
Autant pour moi, mes excuses :(
25 nov. 2003 à 16:40
Le uses du Form1 est pris dans le commentaire. On place le curseur au bon endroit, un coup sur Entrée, et la situation est rétablie ;)
Par contre, la clé générée n'a pas l'air d'émouvoir beaucoup le Form2 : 'Le mot de passe n'est pas correct' me dit-il inlassablement...