Dans le cadre du projet PyShaPass (https://gna.org/projects/pyshapass)
que j'avais évoqué ici le 28 avril 2005, j'ai mis en place l'idée de
Kevin Drapel pour éviter d'utiliser BASE64 comme "mixer" et j'ai fait le
mien ...
En python, ça donne ça :
def pyshapass_mixer(location, length, uppercase, number, special,
verbose = 0):
"""Mix the SHA with indice instead of base64
"""
alphabet = "abcdefghijklmnopqrstuvwxyz"
if uppercase:
alphabet += "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
if number:
alphabet += "0123456789"
if special:
alphabet += '=+-/*.!?:%$_&@"''(){}[]'
if verbose:
print "Alphabet=%s" % (alphabet)
la = len(alphabet)
password = ""
for i in range(int(length)):
password += alphabet[ord(location[i]) % la]
return password
Comme vous pouvez le voir dans
alphabet += '=+-/*.!?:%$_&@"''(){}[]'
j'ai rajouté des signes pour faire les mots de passe mais j'hésite sur
quel signe à rajouter ou pas, est ce que ce signe est facile à faire en
qwerty ? Est ce normal d'utiliser ce signe dans un mot de passe ? etc.
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un
mot de passe ? Une liste de conseil sur untel non à cause de ça, celui
là oui à cause de ça, etc. ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicob
On Fri, 20 Jan 2006 18:05:21 +0100, dede wrote:
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si supporté par le système sur lequel on s'authentifie) est souvent une bonne idée. Mais ce n'est pas très portable ...
Nicob
On Fri, 20 Jan 2006 18:05:21 +0100, dede wrote:
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un
mot de passe ? Une liste de conseil sur untel non à cause de ça, celui
là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si
supporté par le système sur lequel on s'authentifie) est souvent une
bonne idée. Mais ce n'est pas très portable ...
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si supporté par le système sur lequel on s'authentifie) est souvent une bonne idée. Mais ce n'est pas très portable ...
Nicob
Jean-Marc Desperrier
dede wrote:
Dans le cadre du projet PyShaPass (https://gna.org/projects/pyshapass) que j'avais évoqué ici le 28 avril 2005, j'ai mis en place l'idée de Kevin Drapel pour éviter d'utiliser BASE64 comme "mixer" et j'ai fait le mien ...
[...] Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
J'ai relu le message de l'époque : http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/5623125203ab2244/93392afcd6f405ff
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a réellement un biais et non juste une démonstration des capacité du cerveau à "voir des motifs" même là où il n'y a rien de plus que du bruit blanc.
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres éléments. Et il faut un peu plus de rechercher pour comprendre où il est vraiment.
Et changer le mixer ne change rien.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est dû au fait que les données de longueur n en base64 contiennent n*6 bits de données, et que le nombre y de bits d'aléa réellement générés n'était pas forcément multiple de 6.
dede wrote:
Dans le cadre du projet PyShaPass (https://gna.org/projects/pyshapass)
que j'avais évoqué ici le 28 avril 2005, j'ai mis en place l'idée de
Kevin Drapel pour éviter d'utiliser BASE64 comme "mixer" et j'ai fait le
mien ...
[...]
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un
mot de passe ? Une liste de conseil sur untel non à cause de ça, celui
là oui à cause de ça, etc. ?
J'ai relu le message de l'époque :
http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/5623125203ab2244/93392afcd6f405ff
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation
où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a
réellement un biais et non juste une démonstration des capacité du
cerveau à "voir des motifs" même là où il n'y a rien de plus que du
bruit blanc.
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres
éléments. Et il faut un peu plus de rechercher pour comprendre où il est
vraiment.
Et changer le mixer ne change rien.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est
dû au fait que les données de longueur n en base64 contiennent n*6 bits
de données, et que le nombre y de bits d'aléa réellement générés n'était
pas forcément multiple de 6.
Dans le cadre du projet PyShaPass (https://gna.org/projects/pyshapass) que j'avais évoqué ici le 28 avril 2005, j'ai mis en place l'idée de Kevin Drapel pour éviter d'utiliser BASE64 comme "mixer" et j'ai fait le mien ...
[...] Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
J'ai relu le message de l'époque : http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/5623125203ab2244/93392afcd6f405ff
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a réellement un biais et non juste une démonstration des capacité du cerveau à "voir des motifs" même là où il n'y a rien de plus que du bruit blanc.
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres éléments. Et il faut un peu plus de rechercher pour comprendre où il est vraiment.
Et changer le mixer ne change rien.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est dû au fait que les données de longueur n en base64 contiennent n*6 bits de données, et que le nombre y de bits d'aléa réellement générés n'était pas forcément multiple de 6.
dede
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a réellement un biais et non juste une démonstration des capacité du cerveau à "voir des motifs" même là où il n'y a rien de plus que du bruit blanc.
Mon cerveau est trop fort pour voir des N et des M :)
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres éléments. Et il faut un peu plus de rechercher pour comprendre où il est vraiment.
Je vois pas où si on prend /dev/random et plusieurs fois de suite.
Et changer le mixer ne change rien.
Un peu quand même. Si on ajoute les signes, ça augmente la force du mot de passe.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est dû au fait que les données de longueur n en base64 contiennent n*6 bits de données, et que le nombre y de bits d'aléa réellement générés n'était pas forcément multiple de 6.
Hum, le pad ... Exact ! Je n'y aurai pas pensé !
Merci.
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation
où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a
réellement un biais et non juste une démonstration des capacité du
cerveau à "voir des motifs" même là où il n'y a rien de plus que du
bruit blanc.
Mon cerveau est trop fort pour voir des N et des M :)
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres
éléments. Et il faut un peu plus de rechercher pour comprendre où il est
vraiment.
Je vois pas où si on prend /dev/random et plusieurs fois de suite.
Et changer le mixer ne change rien.
Un peu quand même. Si on ajoute les signes, ça augmente la force du mot
de passe.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est
dû au fait que les données de longueur n en base64 contiennent n*6 bits
de données, et que le nombre y de bits d'aléa réellement générés n'était
pas forcément multiple de 6.
Mais dans cette direction, base64 n'introduit pas de biais(*)
Ce qui ne signifie pas qu'il n'y en a pas un, mais c'est une situation où il faut éviter de faire confiance à ses yeux et vérifier qu'il y a réellement un biais et non juste une démonstration des capacité du cerveau à "voir des motifs" même là où il n'y a rien de plus que du bruit blanc.
Mon cerveau est trop fort pour voir des N et des M :)
S'il y a réellement un biais, il n'est pas dû au base64 mais aux autres éléments. Et il faut un peu plus de rechercher pour comprendre où il est vraiment.
Je vois pas où si on prend /dev/random et plusieurs fois de suite.
Et changer le mixer ne change rien.
Un peu quand même. Si on ajoute les signes, ça augmente la force du mot de passe.
(*) Le caractère avant le signe '=' peut ne pas être équi-réparti, c'est dû au fait que les données de longueur n en base64 contiennent n*6 bits de données, et que le nombre y de bits d'aléa réellement générés n'était pas forcément multiple de 6.
Hum, le pad ... Exact ! Je n'y aurai pas pensé !
Merci.
dede
Effectivement, c'est pas très portable :D
Puis ça va être dur à recopier ;)
Donc ça dépend plus des clavier que des OS, suffit de prendre tous les signes utilisés en C, C++, Java et Python en fait ! On cherche les signes des trucs portables et hop !
On Fri, 20 Jan 2006 18:05:21 +0100, dede wrote:
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si supporté par le système sur lequel on s'authentifie) est souvent une bonne idée. Mais ce n'est pas très portable ...
Nicob
Effectivement, c'est pas très portable :D
Puis ça va être dur à recopier ;)
Donc ça dépend plus des clavier que des OS, suffit de prendre tous les
signes utilisés en C, C++, Java et Python en fait !
On cherche les signes des trucs portables et hop !
On Fri, 20 Jan 2006 18:05:21 +0100, dede wrote:
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un
mot de passe ? Une liste de conseil sur untel non à cause de ça, celui
là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si
supporté par le système sur lequel on s'authentifie) est souvent une
bonne idée. Mais ce n'est pas très portable ...
Donc ça dépend plus des clavier que des OS, suffit de prendre tous les signes utilisés en C, C++, Java et Python en fait ! On cherche les signes des trucs portables et hop !
On Fri, 20 Jan 2006 18:05:21 +0100, dede wrote:
Est qu'il existe une norme pour les signes qu'on peut utiliser dans un mot de passe ? Une liste de conseil sur untel non à cause de ça, celui là oui à cause de ça, etc. ?
Pas à ma connaissance. Mais insérer des caractères non-imprimables (si supporté par le système sur lequel on s'authentifie) est souvent une bonne idée. Mais ce n'est pas très portable ...
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
J'ai relancé le code fourni et ça me sort de grande colonne de M quand
même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en
hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16
valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux
bloc où elles se suivent donc c'est principalement les bits de poids
faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données
d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine
les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le
grand nombre de N et M, alors qu'il y a surtout très peu de variation
dans les caractères présents dans cette première colonne, et que cela se
répète dans tout le tableau tous les 4 caractères avec une proportion
énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande
inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu
de 24.
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html : hexdigest() Like digest() except the digest is returned as a string of length 40, containing only hexadecimal digits. This may be used to exchange the value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie shell or c'est apparement ce qu'il se passe (la conversion hexa) sans que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ... Au lieu de chercher dans le module sha de python ce qui donnait le même résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!! Bon départ de week end ;)
J'ai relancé le code fourni et ça me sort de grande colonne de M quand
même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en
hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16
valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux
bloc où elles se suivent donc c'est principalement les bits de poids
faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données
d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine
les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le
grand nombre de N et M, alors qu'il y a surtout très peu de variation
dans les caractères présents dans cette première colonne, et que cela se
répète dans tout le tableau tous les 4 caractères avec une proportion
énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande
inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu
de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html :
hexdigest()
Like digest() except the digest is returned as a string of length
40, containing only hexadecimal digits. This may be used to exchange the
value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans
http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie
shell or c'est apparement ce qu'il se passe (la conversion hexa) sans
que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ...
Au lieu de chercher dans le module sha de python ce qui donnait le même
résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie
binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!!
Bon départ de week end ;)
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html : hexdigest() Like digest() except the digest is returned as a string of length 40, containing only hexadecimal digits. This may be used to exchange the value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie shell or c'est apparement ce qu'il se passe (la conversion hexa) sans que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ... Au lieu de chercher dans le module sha de python ce qui donnait le même résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!! Bon départ de week end ;)
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html : hexdigest() Like digest() except the digest is returned as a string of length 40, containing only hexadecimal digits. This may be used to exchange the value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie shell or c'est apparement ce qu'il se passe (la conversion hexa) sans que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ... Au lieu de chercher dans le module sha de python ce qui donnait le même résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!! Bon départ de week end ;)
Voilà l'option "-binary" de openssl résoud le schmilblick ...
J'ai relancé le code fourni et ça me sort de grande colonne de M
quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en
hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16
valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur
deux bloc où elles se suivent donc c'est principalement les bits de
poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données
d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui
élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que
le grand nombre de N et M, alors qu'il y a surtout très peu de
variation dans les caractères présents dans cette première colonne, et
que cela se répète dans tout le tableau tous les 4 caractères avec une
proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande
inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au
lieu de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html :
hexdigest()
Like digest() except the digest is returned as a string of length
40, containing only hexadecimal digits. This may be used to exchange the
value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans
http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie
shell or c'est apparement ce qu'il se passe (la conversion hexa) sans
que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ...
Au lieu de chercher dans le module sha de python ce qui donnait le même
résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie
binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!!
Bon départ de week end ;)
Voilà l'option "-binary" de openssl résoud le schmilblick ...
J'ai relancé le code fourni et ça me sort de grande colonne de M quand même ... :/
Je crois que j'ai trouvé la source du problème.
C'est quoi hexdigest() ?
J'ai l'impression que tu commence par convertir les données en hexadecimal avant d'encoder en base64.
Donc la source de donnée que tu encode en base64 ne varie que sur 16 valeurs pour chaque octet au lieu de 256. 16 valeurs réparties sur deux bloc où elles se suivent donc c'est principalement les bits de poids faible qui changent.
Et chaque caractère du base64 ne représente que 6 bits de tes données d'entrée, donc au début d'un bloc les 6 bit de poid fort ce qui élimine les 2 qui changent le plus.
Donc finalement l'oeil n'a pas été très performant car il n'y vu que le grand nombre de N et M, alors qu'il y a surtout très peu de variation dans les caractères présents dans cette première colonne, et que cela se répète dans tout le tableau tous les 4 caractères avec une proportion énorme de N, M, O, Y ou Z.
Cependant à l'arrivée, pas de véritable biais, juste une grande inefficacité, chaque bloc de 4 caractères base64 encode 12 bits au lieu de 24.
Oh trop fort ! J'étais sur que c'était un truc du genre :/
De http://python.org/doc/2.4.2/lib/module-sha.html : hexdigest() Like digest() except the digest is returned as a string of length 40, containing only hexadecimal digits. This may be used to exchange the value safely in email or other non-binary environments.
En fait ça vient de la partie shell visible dans http://svn.gna.org/viewcvs/pyshapass/trunk/fun/
La partie python a été faite pour donner le même résultat que la partie shell or c'est apparement ce qu'il se passe (la conversion hexa) sans que ce soit demandé ...
La sortie de openssl sha1 est en hexa :/ J'avais jamais remarqué ... Au lieu de chercher dans le module sha de python ce qui donnait le même résultat, j'aurais pu réfléchir un peu plus ...
Pffff Désolé !
En tout cas, c'est embétant ça car si on peut pas forcer la sortie binaire de openssl il n'y aura pas de version shell :/
En tout cas merci beaucoup !!! Bon départ de week end ;)
Voilà l'option "-binary" de openssl résoud le schmilblick ...
