J'utilise une DLL dans un programme pour implanter le codage BlowFish.
Le problème c'est que je suis obligé de faire confiance à la DLL, car je
n'ai pas les sources et que je ne me sens pas de programmer une telle DLL.
Alors comment savoir si ce que j'ai est bien du BlowFish, ou du "n'importe
quoi" ?
Une personne m'a donné un lien pour vérifier d'après un texte en clair et
une clé (0000000 et 0000000) et je devrais optenir un texte codé bien
précis.
J'ai testé, mais je n'ai pas du tout le même texte ! le soucis c'est que
j'ai essayé avec plusieurs autres logiciels prétendants coder en Blowfish,
et aucun ne sort le même texte codé !
Alors existe t'il un moyen de vérification ? ou est-ce totalement aléatoire
?
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
Arnaud W.
Bonjour,
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement, - soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Les vecteurs de tests sont définis pour valider les implémentations des algorithmes cryptographiques (du moins garantir un certain niveau de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous ne pouvez pas mettre le vecteur de données dans un fichier par copier/coller et tenter de le crypter : le vecteur de test doit être ce qui est lu (donc les octets du fichier) et non ce qui est dans le fichier qui est lu. La nuance est subtile. Par exemple, si une entrée doit être 10100111 (en binaire), mettre cette chaine dans un fichier n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8 octets formés par les codes ascii de la liste des '0' et des '1'). Mais vous le saviez sans doute déjà.
Arnaud W. http://awr.free.fr
Bonjour,
Si les mêmes entrées donnent des résultats différents avec
plusieurs implémentations, c'est que :
- soit vous ne donnez pas les entrées correctement,
- soit les implémentations sont fausses (et donc non compatibles)
- soit votre machine n'a pas le bon encoding (attention au big/little
indian)
- soit une combinaison de ces erreurs.
Les vecteurs de tests sont définis pour valider les implémentations
des algorithmes cryptographiques (du moins garantir un certain niveau
de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous
ne pouvez pas mettre le vecteur de données dans un fichier par
copier/coller et tenter de le crypter : le vecteur de test doit être
ce qui est lu (donc les octets du fichier) et non ce qui est dans le
fichier qui est lu. La nuance est subtile. Par exemple, si une entrée
doit être 10100111 (en binaire), mettre cette chaine dans un fichier
n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8
octets formés par les codes ascii de la liste des '0' et des '1').
Mais vous le saviez sans doute déjà.
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement, - soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Les vecteurs de tests sont définis pour valider les implémentations des algorithmes cryptographiques (du moins garantir un certain niveau de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous ne pouvez pas mettre le vecteur de données dans un fichier par copier/coller et tenter de le crypter : le vecteur de test doit être ce qui est lu (donc les octets du fichier) et non ce qui est dans le fichier qui est lu. La nuance est subtile. Par exemple, si une entrée doit être 10100111 (en binaire), mettre cette chaine dans un fichier n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8 octets formés par les codes ascii de la liste des '0' et des '1'). Mais vous le saviez sans doute déjà.
Arnaud W. http://awr.free.fr
Fr
Bonjour,
Bonjour
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement,
Je pense que je les donne correctement, car je ne rentre qu'un texte et un clé identique sur tout les logiciels
- soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Je ne sais pas ...
Les vecteurs de tests sont définis pour valider les implémentations des algorithmes cryptographiques (du moins garantir un certain niveau de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous ne pouvez pas mettre le vecteur de données dans un fichier par copier/coller et tenter de le crypter : le vecteur de test doit être ce qui est lu (donc les octets du fichier) et non ce qui est dans le fichier qui est lu. La nuance est subtile. Par exemple, si une entrée doit être 10100111 (en binaire), mettre cette chaine dans un fichier n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8 octets formés par les codes ascii de la liste des '0' et des '1'). Mais vous le saviez sans doute déjà.
En effet, je ne rentre que du texte, je ne passe pas par un fichier
Arnaud W. http://awr.free.fr
Merci
Bonjour,
Bonjour
Si les mêmes entrées donnent des résultats différents avec
plusieurs implémentations, c'est que :
- soit vous ne donnez pas les entrées correctement,
Je pense que je les donne correctement, car je ne rentre qu'un texte et un
clé identique sur tout les logiciels
- soit les implémentations sont fausses (et donc non compatibles)
- soit votre machine n'a pas le bon encoding (attention au big/little
indian)
- soit une combinaison de ces erreurs.
Je ne sais pas ...
Les vecteurs de tests sont définis pour valider les implémentations
des algorithmes cryptographiques (du moins garantir un certain niveau
de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous
ne pouvez pas mettre le vecteur de données dans un fichier par
copier/coller et tenter de le crypter : le vecteur de test doit être
ce qui est lu (donc les octets du fichier) et non ce qui est dans le
fichier qui est lu. La nuance est subtile. Par exemple, si une entrée
doit être 10100111 (en binaire), mettre cette chaine dans un fichier
n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8
octets formés par les codes ascii de la liste des '0' et des '1').
Mais vous le saviez sans doute déjà.
En effet, je ne rentre que du texte, je ne passe pas par un fichier
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement,
Je pense que je les donne correctement, car je ne rentre qu'un texte et un clé identique sur tout les logiciels
- soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Je ne sais pas ...
Les vecteurs de tests sont définis pour valider les implémentations des algorithmes cryptographiques (du moins garantir un certain niveau de conformité).
Par exemple, si vous testez un logiciel qui crypte des fichiers, vous ne pouvez pas mettre le vecteur de données dans un fichier par copier/coller et tenter de le crypter : le vecteur de test doit être ce qui est lu (donc les octets du fichier) et non ce qui est dans le fichier qui est lu. La nuance est subtile. Par exemple, si une entrée doit être 10100111 (en binaire), mettre cette chaine dans un fichier n'est pas équivalent (car le logiciel lira non pas 1 octet mais 8 octets formés par les codes ascii de la liste des '0' et des '1'). Mais vous le saviez sans doute déjà.
En effet, je ne rentre que du texte, je ne passe pas par un fichier
Arnaud W. http://awr.free.fr
Merci
ouah
Une personne m'a donné un lien pour vérifier d'après un texte en clair et une clé (0000000 et 0000000) et je devrais optenir un texte codé bien précis.
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement, - soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Pour la comparaison avec les vecteurs de test, vérifiez aussi que vous initialisez l'algorithme avec la bonne longueur de clé et que si votre DLL propose plusieurs modes d'opérations vous utilisez bien le mode ECB (ou éventuellement CBC avec un IV à 0).
Pour le premier vecteur de test (bloc clair et clé à 0), regardez si vous n'obtenez pas les bytes dans le désordre: dans ce cas il s'agirait de votre routine d'output des nombres qui ne fonctionne pas correctement...
ouah
Une personne m'a donné un lien pour vérifier d'après un texte en clair et
une clé (0000000 et 0000000) et je devrais optenir un texte codé bien
précis.
Si les mêmes entrées donnent des résultats différents avec
plusieurs implémentations, c'est que :
- soit vous ne donnez pas les entrées correctement,
- soit les implémentations sont fausses (et donc non compatibles)
- soit votre machine n'a pas le bon encoding (attention au big/little
indian)
- soit une combinaison de ces erreurs.
Pour la comparaison avec les vecteurs de test, vérifiez aussi que vous
initialisez l'algorithme avec la bonne longueur de clé et que si
votre DLL propose plusieurs modes d'opérations vous utilisez bien le mode
ECB (ou éventuellement CBC avec un IV à 0).
Pour le premier vecteur de test (bloc clair et clé à 0), regardez si vous
n'obtenez
pas les bytes dans le désordre: dans ce cas il s'agirait de votre routine
d'output
des nombres qui ne fonctionne pas correctement...
Une personne m'a donné un lien pour vérifier d'après un texte en clair et une clé (0000000 et 0000000) et je devrais optenir un texte codé bien précis.
Si les mêmes entrées donnent des résultats différents avec plusieurs implémentations, c'est que : - soit vous ne donnez pas les entrées correctement, - soit les implémentations sont fausses (et donc non compatibles) - soit votre machine n'a pas le bon encoding (attention au big/little indian) - soit une combinaison de ces erreurs.
Pour la comparaison avec les vecteurs de test, vérifiez aussi que vous initialisez l'algorithme avec la bonne longueur de clé et que si votre DLL propose plusieurs modes d'opérations vous utilisez bien le mode ECB (ou éventuellement CBC avec un IV à 0).
Pour le premier vecteur de test (bloc clair et clé à 0), regardez si vous n'obtenez pas les bytes dans le désordre: dans ce cas il s'agirait de votre routine d'output des nombres qui ne fonctionne pas correctement...
ouah
Arnaud W.
C'est le même problème qu'avec un fichier : les vecteurs sont donnés en héxadécimal.
Si vous devez entrer AF01 (soit 2 octects) et que vous les tapez dans un champ texte, ce n'est pas la même chose : cela donne comme entrée le code ASCII de 'A', puis 'B', puis '0', puis '1' (soit 4 octets) soit en héxa 41463031 (rien à voir avec AF01 donc). Et ceci si l'encoding du champ texte est ASCII standard.
En résumé : La valeur héxadécimale AF01 n'est pas équivalente à la valeur héxadécimale correspondant aux caractères de la chaîne "AF01".
Il faut pouvoir fournir les données en binaire ou alors essayer d'encoder correctement les données binaires en ASCII. Par exemple, avec la table ASCII suivante : http://www.crossref.org/02publishers/ascii_chart.htm
Avec AF01 cela donne : 1er octect = AF (base 16) = 175 (en décimal) 2ème octet = 01 (base 16) = 01 (en décimal) Pour taper ces deux caractères sur windows, on peut faire ALT+175 puis ALT+01 (car ils ne correspondent à aucune touche de clavier standard)
Mais tout dépend comment le soft interprête le champ texte (son encoding par défaut)...
Arnaud W. http://awr.free.fr
C'est le même problème qu'avec un fichier : les vecteurs sont donnés
en héxadécimal.
Si vous devez entrer AF01 (soit 2 octects) et que vous les tapez dans
un champ texte, ce n'est pas la même chose : cela donne comme entrée
le code ASCII de 'A', puis 'B', puis '0', puis '1' (soit 4 octets) soit
en héxa 41463031 (rien à voir avec AF01 donc). Et ceci si l'encoding
du champ texte est ASCII standard.
En résumé : La valeur héxadécimale AF01 n'est pas équivalente à
la valeur héxadécimale correspondant aux caractères de la chaîne
"AF01".
Il faut pouvoir fournir les données en binaire ou alors essayer
d'encoder correctement les données binaires en ASCII. Par exemple,
avec la table ASCII suivante :
http://www.crossref.org/02publishers/ascii_chart.htm
Avec AF01 cela donne :
1er octect = AF (base 16) = 175 (en décimal)
2ème octet = 01 (base 16) = 01 (en décimal)
Pour taper ces deux caractères sur windows, on peut faire ALT+175 puis
ALT+01 (car ils ne correspondent à aucune touche de clavier standard)
Mais tout dépend comment le soft interprête le champ texte (son
encoding par défaut)...
C'est le même problème qu'avec un fichier : les vecteurs sont donnés en héxadécimal.
Si vous devez entrer AF01 (soit 2 octects) et que vous les tapez dans un champ texte, ce n'est pas la même chose : cela donne comme entrée le code ASCII de 'A', puis 'B', puis '0', puis '1' (soit 4 octets) soit en héxa 41463031 (rien à voir avec AF01 donc). Et ceci si l'encoding du champ texte est ASCII standard.
En résumé : La valeur héxadécimale AF01 n'est pas équivalente à la valeur héxadécimale correspondant aux caractères de la chaîne "AF01".
Il faut pouvoir fournir les données en binaire ou alors essayer d'encoder correctement les données binaires en ASCII. Par exemple, avec la table ASCII suivante : http://www.crossref.org/02publishers/ascii_chart.htm
Avec AF01 cela donne : 1er octect = AF (base 16) = 175 (en décimal) 2ème octet = 01 (base 16) = 01 (en décimal) Pour taper ces deux caractères sur windows, on peut faire ALT+175 puis ALT+01 (car ils ne correspondent à aucune touche de clavier standard)
Mais tout dépend comment le soft interprête le champ texte (son encoding par défaut)...
