Sous Windows ça s'appelle comment, ça ?
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive,
mais on en chie.
Sous Windows ça s'appelle comment, ça ?
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive,
mais on en chie.
Sous Windows ça s'appelle comment, ça ?
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive,
mais on en chie.
[Désolé pour le retard, obligations familiales qui m'ont accessoirement
permis de tester un truc]
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il
question de comparaison ?
Tu dis, à juste titre, que ce qui importe le plus ce n'est pas
l'algorithme de cryptage que l'on choisi, mais la clé que l'on y
associe.
Pour ma part je me contente de dire que, si l'on rapporte
cette phrase à un algorithme de hachage, donc si l'on doit définir ce
qui est le facteur le plus important dans un tel algorithme, alors
c'est le nombre de bit qui ressort ; autrement dit que le plus
important ce n'est pas l'algorithme de hachage que l'on choisi, mais le
nombre de bit sur lequel il travail.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations
(importance forte de la clé ou du nombre de bit, par rapport à
l'importance faible de l'algrithme) est plus limité dans le cas d'un
algorithme de hachage. En effet, le nombre de bit est directement lié à
celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec
des clés de longueur/robustesse variable.
Rapporté à la pratique, cette affirmation revient donc à dire que
l'algorithme de hachage choisi importe peu, tant qu'il fait parti de
ceux utilisant le plus grand nombre de bits.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant
aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux).
2) J'ai soumis ses onze hash au dictionnaire déjà cité.
3) Dans six cas, il ne m'a rien retourné.
4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai
donc exclus, peut-être à tort, cette chaine.
5) Dans les quatre cas restant, il a bien trouvé quelque chose
correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais
utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop
faible pour en tirer de réelle conclusion, mais que le fait était là,
c'était possible.
Maintenant, après avoir lu ton message, je rajouterais que j'aurais du
jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé
l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
[Désolé pour le retard, obligations familiales qui m'ont accessoirement
permis de tester un truc]
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il
question de comparaison ?
Tu dis, à juste titre, que ce qui importe le plus ce n'est pas
l'algorithme de cryptage que l'on choisi, mais la clé que l'on y
associe.
Pour ma part je me contente de dire que, si l'on rapporte
cette phrase à un algorithme de hachage, donc si l'on doit définir ce
qui est le facteur le plus important dans un tel algorithme, alors
c'est le nombre de bit qui ressort ; autrement dit que le plus
important ce n'est pas l'algorithme de hachage que l'on choisi, mais le
nombre de bit sur lequel il travail.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations
(importance forte de la clé ou du nombre de bit, par rapport à
l'importance faible de l'algrithme) est plus limité dans le cas d'un
algorithme de hachage. En effet, le nombre de bit est directement lié à
celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec
des clés de longueur/robustesse variable.
Rapporté à la pratique, cette affirmation revient donc à dire que
l'algorithme de hachage choisi importe peu, tant qu'il fait parti de
ceux utilisant le plus grand nombre de bits.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant
aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux).
2) J'ai soumis ses onze hash au dictionnaire déjà cité.
3) Dans six cas, il ne m'a rien retourné.
4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai
donc exclus, peut-être à tort, cette chaine.
5) Dans les quatre cas restant, il a bien trouvé quelque chose
correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais
utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop
faible pour en tirer de réelle conclusion, mais que le fait était là,
c'était possible.
Maintenant, après avoir lu ton message, je rajouterais que j'aurais du
jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé
l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
[Désolé pour le retard, obligations familiales qui m'ont accessoirement
permis de tester un truc]
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il
question de comparaison ?
Tu dis, à juste titre, que ce qui importe le plus ce n'est pas
l'algorithme de cryptage que l'on choisi, mais la clé que l'on y
associe.
Pour ma part je me contente de dire que, si l'on rapporte
cette phrase à un algorithme de hachage, donc si l'on doit définir ce
qui est le facteur le plus important dans un tel algorithme, alors
c'est le nombre de bit qui ressort ; autrement dit que le plus
important ce n'est pas l'algorithme de hachage que l'on choisi, mais le
nombre de bit sur lequel il travail.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations
(importance forte de la clé ou du nombre de bit, par rapport à
l'importance faible de l'algrithme) est plus limité dans le cas d'un
algorithme de hachage. En effet, le nombre de bit est directement lié à
celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec
des clés de longueur/robustesse variable.
Rapporté à la pratique, cette affirmation revient donc à dire que
l'algorithme de hachage choisi importe peu, tant qu'il fait parti de
ceux utilisant le plus grand nombre de bits.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant
aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux).
2) J'ai soumis ses onze hash au dictionnaire déjà cité.
3) Dans six cas, il ne m'a rien retourné.
4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai
donc exclus, peut-être à tort, cette chaine.
5) Dans les quatre cas restant, il a bien trouvé quelque chose
correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais
utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop
faible pour en tirer de réelle conclusion, mais que le fait était là,
c'était possible.
Maintenant, après avoir lu ton message, je rajouterais que j'aurais du
jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé
l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
Autrement dit, que le mot de passe transite en clair ou en crypté ne
change pas grand chose. C'est plus sur lorsque c'est crypté, mais sauf
à considérer que les données sont hyper sensibles, le cryptage est
relativement inutile à ce niveau là. Dans tous les cas, si un mot de
passe non crypté est intercepté, cela signifie qu'il y a une faille de
sécurité nettement plus importante que le simple fait que les données
transitent en clair.
Autrement dit, que le mot de passe transite en clair ou en crypté ne
change pas grand chose. C'est plus sur lorsque c'est crypté, mais sauf
à considérer que les données sont hyper sensibles, le cryptage est
relativement inutile à ce niveau là. Dans tous les cas, si un mot de
passe non crypté est intercepté, cela signifie qu'il y a une faille de
sécurité nettement plus importante que le simple fait que les données
transitent en clair.
Autrement dit, que le mot de passe transite en clair ou en crypté ne
change pas grand chose. C'est plus sur lorsque c'est crypté, mais sauf
à considérer que les données sont hyper sensibles, le cryptage est
relativement inutile à ce niveau là. Dans tous les cas, si un mot de
passe non crypté est intercepté, cela signifie qu'il y a une faille de
sécurité nettement plus importante que le simple fait que les données
transitent en clair.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément
de chance à chaque fois que je fais mumuse avec des chaînes aléatoires
et des dictionnaires.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément
de chance à chaque fois que je fais mumuse avec des chaînes aléatoires
et des dictionnaires.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément
de chance à chaque fois que je fais mumuse avec des chaînes aléatoires
et des dictionnaires.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Tu as raison sur la conclusion, mais pas sur les arguments.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
Cette fois-ci, il n'y a pas de doute sur l'interprétation de tes propos,
mais je n'y crois pas une seule seconde ; j'espère que tu ne le prendras pas
mal. J'expliquerai un peu plus loin pourquoi.
Peux-tu montrer les chaînes en question ?
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
Là encore, j'aimerais voir les chaînes en question.
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
Il n'y a pas que ça. MD5 existe depuis longtemps, et plein de monde
l'utilise pour plein de trucs différents, et en particulier comme clef
d'indexation.
L'exemple qui me vient immédiatement à l'esprit concerne MD4
et pas MD5, mais il devrait illustrer ce que je veux dire : sur le réseau
eDonkey, les fichiers sont identifiés par un MD4, et les tranches de
fichiers aussi. S'il y avait des collision aussi fréquentes que ce que tu
racontes, ce ne serait juste pas tenable, les gens passeraient leur temps à
avoir des fichiers avec des tranches mélangées.
Des collisions pour des fonctions de hachage standard, c'est quelque chose
de surveillé de très très près. S'il y en avait autant que tu dis, on en
aurait entendu parler bien avant 2004.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Tu as raison sur la conclusion, mais pas sur les arguments.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
Cette fois-ci, il n'y a pas de doute sur l'interprétation de tes propos,
mais je n'y crois pas une seule seconde ; j'espère que tu ne le prendras pas
mal. J'expliquerai un peu plus loin pourquoi.
Peux-tu montrer les chaînes en question ?
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
Là encore, j'aimerais voir les chaînes en question.
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
Il n'y a pas que ça. MD5 existe depuis longtemps, et plein de monde
l'utilise pour plein de trucs différents, et en particulier comme clef
d'indexation.
L'exemple qui me vient immédiatement à l'esprit concerne MD4
et pas MD5, mais il devrait illustrer ce que je veux dire : sur le réseau
eDonkey, les fichiers sont identifiés par un MD4, et les tranches de
fichiers aussi. S'il y avait des collision aussi fréquentes que ce que tu
racontes, ce ne serait juste pas tenable, les gens passeraient leur temps à
avoir des fichiers avec des tranches mélangées.
Des collisions pour des fonctions de hachage standard, c'est quelque chose
de surveillé de très très près. S'il y en avait autant que tu dis, on en
aurait entendu parler bien avant 2004.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Tu as raison sur la conclusion, mais pas sur les arguments.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
Cette fois-ci, il n'y a pas de doute sur l'interprétation de tes propos,
mais je n'y crois pas une seule seconde ; j'espère que tu ne le prendras pas
mal. J'expliquerai un peu plus loin pourquoi.
Peux-tu montrer les chaînes en question ?
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
Là encore, j'aimerais voir les chaînes en question.
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
Il n'y a pas que ça. MD5 existe depuis longtemps, et plein de monde
l'utilise pour plein de trucs différents, et en particulier comme clef
d'indexation.
L'exemple qui me vient immédiatement à l'esprit concerne MD4
et pas MD5, mais il devrait illustrer ce que je veux dire : sur le réseau
eDonkey, les fichiers sont identifiés par un MD4, et les tranches de
fichiers aussi. S'il y avait des collision aussi fréquentes que ce que tu
racontes, ce ne serait juste pas tenable, les gens passeraient leur temps à
avoir des fichiers avec des tranches mélangées.
Des collisions pour des fonctions de hachage standard, c'est quelque chose
de surveillé de très très près. S'il y en avait autant que tu dis, on en
aurait entendu parler bien avant 2004.
je pense que tu oublies la compromission au niveau du réseau local :
A mon avis le risque est plus là que en aval.
je pense que tu oublies la compromission au niveau du réseau local :
A mon avis le risque est plus là que en aval.
je pense que tu oublies la compromission au niveau du réseau local :
A mon avis le risque est plus là que en aval.
Tu peux fournir ces chaines? Et/ou le script?
Du coup, en avoir une quinzaine ça m'intéresserait.
Tu peux fournir ces chaines? Et/ou le script?
Du coup, en avoir une quinzaine ça m'intéresserait.
Tu peux fournir ces chaines? Et/ou le script?
Du coup, en avoir une quinzaine ça m'intéresserait.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
C'est d'ailleurs l'utilisation la plus répandue avec le cryptage des
données sensibles il me semble, non ?
J'en suis conscient. Avant cette discussion, mon impression tenait
plutôt de, "p'tain mais bordel c'est pas possible d'avoir autant de
collisions", parce que mes essais au fil des ans m'en donnait quelques
unes. Puis je t'ai lu et j'ai lu tes arguments et j'ai décidé de faire
mon script.
Comme je l'ai dit, l'idée derrière se script était de faire un
comptage sur un échantillon plus précis et à vrai dire j'envisageais
deux cas de figure. Soit j'avais raison (ce dont je doutais de plus en
plus), auquel cas j'aurais eu des collisions par centaines, voire par
millier, et il était inutile de conserver la trace des chaînes. Soit
c'est toi qui avait raison (ce qui me semblait plus réaliste) et il
était là aussi inutile de conserver la trace des chaînes, puisqu'il n'y
en aurait aucune.
Au final, la conclusion de ce test, c'est que MD5 a jeté une
malédiction sur moi et s'évertue à réaliser l'impossible lorsque c'est
moi qui fait mumuse avec.
Je m'en doute un peu. D'un autre côté, toi qui connais et comprend
assurément bien mieux que moi l'algorithme de MD5, *peut-être* que cela
vient de la nature et de la taille (relative) des chaînes utilisées
pour les tests.
Rapporté à MD5, ça donnerait quelque chose comme, "[peut-être que]
avec les chaînes courtes l'algorithme n'a le temps de donner tout ce
qu'il a et temps à produire plus de collision".
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
C'est d'ailleurs l'utilisation la plus répandue avec le cryptage des
données sensibles il me semble, non ?
J'en suis conscient. Avant cette discussion, mon impression tenait
plutôt de, "p'tain mais bordel c'est pas possible d'avoir autant de
collisions", parce que mes essais au fil des ans m'en donnait quelques
unes. Puis je t'ai lu et j'ai lu tes arguments et j'ai décidé de faire
mon script.
Comme je l'ai dit, l'idée derrière se script était de faire un
comptage sur un échantillon plus précis et à vrai dire j'envisageais
deux cas de figure. Soit j'avais raison (ce dont je doutais de plus en
plus), auquel cas j'aurais eu des collisions par centaines, voire par
millier, et il était inutile de conserver la trace des chaînes. Soit
c'est toi qui avait raison (ce qui me semblait plus réaliste) et il
était là aussi inutile de conserver la trace des chaînes, puisqu'il n'y
en aurait aucune.
Au final, la conclusion de ce test, c'est que MD5 a jeté une
malédiction sur moi et s'évertue à réaliser l'impossible lorsque c'est
moi qui fait mumuse avec.
Je m'en doute un peu. D'un autre côté, toi qui connais et comprend
assurément bien mieux que moi l'algorithme de MD5, *peut-être* que cela
vient de la nature et de la taille (relative) des chaînes utilisées
pour les tests.
Rapporté à MD5, ça donnerait quelque chose comme, "[peut-être que]
avec les chaînes courtes l'algorithme n'a le temps de donner tout ce
qu'il a et temps à produire plus de collision".
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
C'est d'ailleurs l'utilisation la plus répandue avec le cryptage des
données sensibles il me semble, non ?
J'en suis conscient. Avant cette discussion, mon impression tenait
plutôt de, "p'tain mais bordel c'est pas possible d'avoir autant de
collisions", parce que mes essais au fil des ans m'en donnait quelques
unes. Puis je t'ai lu et j'ai lu tes arguments et j'ai décidé de faire
mon script.
Comme je l'ai dit, l'idée derrière se script était de faire un
comptage sur un échantillon plus précis et à vrai dire j'envisageais
deux cas de figure. Soit j'avais raison (ce dont je doutais de plus en
plus), auquel cas j'aurais eu des collisions par centaines, voire par
millier, et il était inutile de conserver la trace des chaînes. Soit
c'est toi qui avait raison (ce qui me semblait plus réaliste) et il
était là aussi inutile de conserver la trace des chaînes, puisqu'il n'y
en aurait aucune.
Au final, la conclusion de ce test, c'est que MD5 a jeté une
malédiction sur moi et s'évertue à réaliser l'impossible lorsque c'est
moi qui fait mumuse avec.
Je m'en doute un peu. D'un autre côté, toi qui connais et comprend
assurément bien mieux que moi l'algorithme de MD5, *peut-être* que cela
vient de la nature et de la taille (relative) des chaînes utilisées
pour les tests.
Rapporté à MD5, ça donnerait quelque chose comme, "[peut-être que]
avec les chaînes courtes l'algorithme n'a le temps de donner tout ce
qu'il a et temps à produire plus de collision".
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
Le 21 me semble bizarre. Tu ne confondrais pas avec 0x21 ?
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
Tu pourrais dire avec quel site tu l'as essayé, voire re-lancer l'essai, y
investir encore un petit peu de ton karma exceptionnel, et noter les
résultats.
Considération similaire : dans la mesure où la taille du fichier intervient
dans le calcul du MD5 d'une manière particulière, je soupçonne qu'on ne sait
faire que des collisions qui ont la même taille.
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Il pourrait y avoir un bug dans tes scripts, ou bien dans le site web que tu
interroges.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
Le 21 me semble bizarre. Tu ne confondrais pas avec 0x21 ?
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
Tu pourrais dire avec quel site tu l'as essayé, voire re-lancer l'essai, y
investir encore un petit peu de ton karma exceptionnel, et noter les
résultats.
Considération similaire : dans la mesure où la taille du fichier intervient
dans le calcul du MD5 d'une manière particulière, je soupçonne qu'on ne sait
faire que des collisions qui ont la même taille.
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Il pourrait y avoir un bug dans tes scripts, ou bien dans le site web que tu
interroges.
Tout ce que je peux te dire, c'est que chacune résulte de :
my $last = int(rand(100))+10;
for( my $i = 0 ; $i < $last ; $i++ )
{ $string .= chr(int(rand(106))+21); }
Le 21 me semble bizarre. Tu ne confondrais pas avec 0x21 ?
J'explique plus bas pourquoi c'est tout ce que je peux te dire.
Tu pourrais dire avec quel site tu l'as essayé, voire re-lancer l'essai, y
investir encore un petit peu de ton karma exceptionnel, et noter les
résultats.
Considération similaire : dans la mesure où la taille du fichier intervient
dans le calcul du MD5 d'une manière particulière, je soupçonne qu'on ne sait
faire que des collisions qui ont la même taille.
Franchement, à part la malédiction dont j'ai parlé plus haut, je ne
vois pas d'autres explications pour le résultat de mes tests.
Il pourrait y avoir un bug dans tes scripts, ou bien dans le site web que tu
interroges.
Mais ... La clef publique, enfin celle qui sert à décoder, doit ê tre
dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, pe ut
importe qu'elle se balade dans la nature ou non, elle ne permet ni de
se faire passer pour toi, ni de décrypter les flux interceptés (sau f si
l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui
n'existe plus il me semble).
Mais ... La clef publique, enfin celle qui sert à décoder, doit ê tre
dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, pe ut
importe qu'elle se balade dans la nature ou non, elle ne permet ni de
se faire passer pour toi, ni de décrypter les flux interceptés (sau f si
l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui
n'existe plus il me semble).
Mais ... La clef publique, enfin celle qui sert à décoder, doit ê tre
dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, pe ut
importe qu'elle se balade dans la nature ou non, elle ne permet ni de
se faire passer pour toi, ni de décrypter les flux interceptés (sau f si
l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui
n'existe plus il me semble).
