Étape 4 du simple algo:
...
Ici, j'ai fait un peu vite la partie de l'algo pour le prolongement de
la clef de session; faudrait regarder la façon la plus sûre. Mais, on
pourrait faire les additions et les xor avec d'autres valeurs:
Par exemple, au lieu de faire k5 = ((k2 + k3) xor m1) + k4
on pourrait faire (en ajoutant le modulo que je n'ai pas mis pour que ce
soit plus simple à l'oeil):
k5 =( ((k2 + m1) xor k3) + k4) Modulo 256
Étape 4 du simple algo:
...
Ici, j'ai fait un peu vite la partie de l'algo pour le prolongement de
la clef de session; faudrait regarder la façon la plus sûre. Mais, on
pourrait faire les additions et les xor avec d'autres valeurs:
Par exemple, au lieu de faire k5 = ((k2 + k3) xor m1) + k4
on pourrait faire (en ajoutant le modulo que je n'ai pas mis pour que ce
soit plus simple à l'oeil):
k5 =( ((k2 + m1) xor k3) + k4) Modulo 256
Étape 4 du simple algo:
...
Ici, j'ai fait un peu vite la partie de l'algo pour le prolongement de
la clef de session; faudrait regarder la façon la plus sûre. Mais, on
pourrait faire les additions et les xor avec d'autres valeurs:
Par exemple, au lieu de faire k5 = ((k2 + k3) xor m1) + k4
on pourrait faire (en ajoutant le modulo que je n'ai pas mis pour que ce
soit plus simple à l'oeil):
k5 =( ((k2 + m1) xor k3) + k4) Modulo 256
Étape 4 du simple algo:
Cassé.
Et je me suis amélioré au niveau de la rapidité :-)
Histoire de voir si je n'ai pas fait d'erreur :
M=[ 99; 78; 45; 85; 1;225]
K=[251;201;178;155]
Donne-t-il bien le chiffré C=[103; 77; 22;113;100;102] ?
Étape 4 du simple algo:
Cassé.
Et je me suis amélioré au niveau de la rapidité :-)
Histoire de voir si je n'ai pas fait d'erreur :
M=[ 99; 78; 45; 85; 1;225]
K=[251;201;178;155]
Donne-t-il bien le chiffré C=[103; 77; 22;113;100;102] ?
Étape 4 du simple algo:
Cassé.
Et je me suis amélioré au niveau de la rapidité :-)
Histoire de voir si je n'ai pas fait d'erreur :
M=[ 99; 78; 45; 85; 1;225]
K=[251;201;178;155]
Donne-t-il bien le chiffré C=[103; 77; 22;113;100;102] ?
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
L'avez-vous calculé à l'aide de Scilab?
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
L'avez-vous calculé à l'aide de Scilab?
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
L'avez-vous calculé à l'aide de Scilab?
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
l'avez-vous calculé à partir de l'algo, du chiffré et du clair? Car
j'aimerais savoir dans un premier temps s'il est possible, à partir
seulement du chiffré et de l'algo, de trouver le clair. C'est le point le
plus important.
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel on doit
essayer de trouver le clair avec l'aide de l'algo seulement? Mais avec la
1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo
256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3 du
'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai mis la
ligne de code simplifiée selon que vous aviez suggéré disant qu'il n'y avait
pas de différence entre elle et celle de l'étape 3. Voudriez-vous tentez
l'expérience avec la ligne de l'étape 3 aussi? C'est à dire, avec la ligne
qui n'est pas simplifiée; et cela afin de me dire si l'algo est cassable de
cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
l'avez-vous calculé à partir de l'algo, du chiffré et du clair? Car
j'aimerais savoir dans un premier temps s'il est possible, à partir
seulement du chiffré et de l'algo, de trouver le clair. C'est le point le
plus important.
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel on doit
essayer de trouver le clair avec l'aide de l'algo seulement? Mais avec la
1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo
256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3 du
'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai mis la
ligne de code simplifiée selon que vous aviez suggéré disant qu'il n'y avait
pas de différence entre elle et celle de l'étape 3. Voudriez-vous tentez
l'expérience avec la ligne de l'étape 3 aussi? C'est à dire, avec la ligne
qui n'est pas simplifiée; et cela afin de me dire si l'algo est cassable de
cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
l'avez-vous calculé à partir de l'algo, du chiffré et du clair? Car
j'aimerais savoir dans un premier temps s'il est possible, à partir
seulement du chiffré et de l'algo, de trouver le clair. C'est le point le
plus important.
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel on doit
essayer de trouver le clair avec l'aide de l'algo seulement? Mais avec la
1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo
256
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3 du
'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai mis la
ligne de code simplifiée selon que vous aviez suggéré disant qu'il n'y avait
pas de différence entre elle et celle de l'étape 3. Voudriez-vous tentez
l'expérience avec la ligne de l'étape 3 aussi? C'est à dire, avec la ligne
qui n'est pas simplifiée; et cela afin de me dire si l'algo est cassable de
cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
Si si. Il l'est. Je m'étais juste trompé dans le programme. Même pas
dans l'algo lui-même mais dans l'appel de fonction : j'avais mis 255 au
lieu de 225 pour le clair...
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Attaque à clair connu.Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Il est possible, à mon avis, de remonter jusqu'au clair avec le chiffré
seul. Là ou tu vois un calcul itératif compliqué, il n'y a que deux
couches de chiffrement successifs et distincts introduisant beaucoup de
redondances.
La clé de session est fonction de la phrase de passe.
S=f(M,P) qui peut être calculé *totalement* avant le chiffrement.
C=f(M,S) qui est le chiffrement proprement dit.
Je ne crains que je ne sache pas expliquer de manière claire mes calculs
dans ce cas.Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
L'algo a été complétement inversé.
Tu peux augmenter à plein
d'octets la phrase de passe ou le chiffré que ça ne changera strictement
rien. Faire de la force brute sur 4 octet reste facile et ce n'est pas
représentatif des cas ou cette phrase de passe est plus longue.Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Je pense que c'est possible, vu mes calculs théoriques.
Mais je n'ai pas
la quantité de temps avec mes compétences pour ce faire. Il faudrait
augmenter l'un ou l'autre et ce n'est pas à l'ordre du jour.
Ce n'est pas que c'est compliqué : les idées suivent la secondes où
j'ai fini de comprendres tes phrases de dix kilomètres. Après, il faut
rédiger, prototyper, tester...Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je travaille avec les spécifications de départ. Les changements vont
juste me faire perdre du temps sans solidifier le procédé.Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
Aucun intérêt. J'ai apprécié la simplification apporté au prototype
qui évite de me faire perdre du temps. Compliquer les plus ou les moins
ne changera rien.
J'ai suffisament prouvé que je savais casser tes produits en en apportant
la preuve pour me passer de complications inutiles.C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Il me faut des spécifications complètes, claires, sans ambiguité,
uniques, stables, documentées avec des exemples de résultats de calculs.
Tu cumules deux algos de chiffrement : un pour construire D'ABORD une clé
de session aussi longue que le clair à la base de la phrase de passe,
un
autre pour chiffrer le clair à l'aide de la clé de session qui n'est
pas aléatoire.
C'est faible, lourd et apporte une sécurité illusoire.
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
Si si. Il l'est. Je m'étais juste trompé dans le programme. Même pas
dans l'algo lui-même mais dans l'appel de fonction : j'avais mis 255 au
lieu de 225 pour le clair...
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Attaque à clair connu.
Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Il est possible, à mon avis, de remonter jusqu'au clair avec le chiffré
seul. Là ou tu vois un calcul itératif compliqué, il n'y a que deux
couches de chiffrement successifs et distincts introduisant beaucoup de
redondances.
La clé de session est fonction de la phrase de passe.
S=f(M,P) qui peut être calculé *totalement* avant le chiffrement.
C=f(M,S) qui est le chiffrement proprement dit.
Je ne crains que je ne sache pas expliquer de manière claire mes calculs
dans ce cas.
Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
L'algo a été complétement inversé.
Tu peux augmenter à plein
d'octets la phrase de passe ou le chiffré que ça ne changera strictement
rien. Faire de la force brute sur 4 octet reste facile et ce n'est pas
représentatif des cas ou cette phrase de passe est plus longue.
Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Je pense que c'est possible, vu mes calculs théoriques.
Mais je n'ai pas
la quantité de temps avec mes compétences pour ce faire. Il faudrait
augmenter l'un ou l'autre et ce n'est pas à l'ordre du jour.
Ce n'est pas que c'est compliqué : les idées suivent la secondes où
j'ai fini de comprendres tes phrases de dix kilomètres. Après, il faut
rédiger, prototyper, tester...
Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je travaille avec les spécifications de départ. Les changements vont
juste me faire perdre du temps sans solidifier le procédé.
Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
Aucun intérêt. J'ai apprécié la simplification apporté au prototype
qui évite de me faire perdre du temps. Compliquer les plus ou les moins
ne changera rien.
J'ai suffisament prouvé que je savais casser tes produits en en apportant
la preuve pour me passer de complications inutiles.
C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Il me faut des spécifications complètes, claires, sans ambiguité,
uniques, stables, documentées avec des exemples de résultats de calculs.
Tu cumules deux algos de chiffrement : un pour construire D'ABORD une clé
de session aussi longue que le clair à la base de la phrase de passe,
un
autre pour chiffrer le clair à l'aide de la clé de session qui n'est
pas aléatoire.
C'est faible, lourd et apporte une sécurité illusoire.
Cassé.
Non. Meilleure chance la prochaine fois ;-)
Juste une valeur à corriger.
Si si. Il l'est. Je m'étais juste trompé dans le programme. Même pas
dans l'algo lui-même mais dans l'appel de fonction : j'avais mis 255 au
lieu de 225 pour le clair...
L'avez-vous calculé seulement à partir de l'algo et du chiffré ou bien
l'avez-vous calculé à partir de l'algo, du chiffré et du clair?
Attaque à clair connu.Car j'aimerais savoir dans un premier temps s'il est possible, à
partir seulement du chiffré et de l'algo, de trouver le clair. C'est
le point le plus important.
Il est possible, à mon avis, de remonter jusqu'au clair avec le chiffré
seul. Là ou tu vois un calcul itératif compliqué, il n'y a que deux
couches de chiffrement successifs et distincts introduisant beaucoup de
redondances.
La clé de session est fonction de la phrase de passe.
S=f(M,P) qui peut être calculé *totalement* avant le chiffrement.
C=f(M,S) qui est le chiffrement proprement dit.
Je ne crains que je ne sache pas expliquer de manière claire mes calculs
dans ce cas.Avez-vous essayé en cherchant plusieurs clefs possibles (par logiciel
ou autres) ou bien avez-vous tentez par une inversion de l'algo
seulement?
L'algo a été complétement inversé.
Tu peux augmenter à plein
d'octets la phrase de passe ou le chiffré que ça ne changera strictement
rien. Faire de la force brute sur 4 octet reste facile et ce n'est pas
représentatif des cas ou cette phrase de passe est plus longue.Voici le chiffré 225-111-037-088-088-057 suivant à partir duquel
on doit essayer de trouver le clair avec l'aide de l'algo seulement?
Je pense que c'est possible, vu mes calculs théoriques.
Mais je n'ai pas
la quantité de temps avec mes compétences pour ce faire. Il faudrait
augmenter l'un ou l'autre et ce n'est pas à l'ordre du jour.
Ce n'est pas que c'est compliqué : les idées suivent la secondes où
j'ai fini de comprendres tes phrases de dix kilomètres. Après, il faut
rédiger, prototyper, tester...Mais avec la 1re façon, c'est à dire avec c(x+1) = (((k1 + m(x+1)) xor
k2) + k1) Modulo 256
Je travaille avec les spécifications de départ. Les changements vont
juste me faire perdre du temps sans solidifier le procédé.Je fais remarquer que je n'avais pas reproduis exactement l'étape 3
du 'Simple algo' dans le 1er message de ce fil (étape 4). Car j'ai
mis la ligne de code simplifiée selon que vous aviez suggéré disant
qu'il n'y avait pas de différence entre elle et celle de l'étape 3.
Voudriez-vous tentez l'expérience avec la ligne de l'étape 3 aussi?
Aucun intérêt. J'ai apprécié la simplification apporté au prototype
qui évite de me faire perdre du temps. Compliquer les plus ou les moins
ne changera rien.
J'ai suffisament prouvé que je savais casser tes produits en en apportant
la preuve pour me passer de complications inutiles.C'est à dire, avec la ligne qui n'est pas simplifiée; et cela afin de
me dire si l'algo est cassable de cette façon.
Voici donc le chiffré, à partir duquel trouver le clair:
129-153-008-071-039-248
Il me faut des spécifications complètes, claires, sans ambiguité,
uniques, stables, documentées avec des exemples de résultats de calculs.
Tu cumules deux algos de chiffrement : un pour construire D'ABORD une clé
de session aussi longue que le clair à la base de la phrase de passe,
un
autre pour chiffrer le clair à l'aide de la clé de session qui n'est
pas aléatoire.
C'est faible, lourd et apporte une sécurité illusoire.
Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de l'algo
et du chiffré 6-16-19-13-31-21 ? "
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de l'algo
et du chiffré 6-16-19-13-31-21 ? "
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de l'algo
et du chiffré 6-16-19-13-31-21 ? "
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la
clé à partir du chiffré seul, mais trouve la clé à partir du moment où
il sait que le clair était une image JPEG. Cette seule info suffit à
permettre une attaque réussie.
...
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors
là, oui, on peut faire quelque chose.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la
clé à partir du chiffré seul, mais trouve la clé à partir du moment où
il sait que le clair était une image JPEG. Cette seule info suffit à
permettre une attaque réussie.
...
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors
là, oui, on peut faire quelque chose.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la
clé à partir du chiffré seul, mais trouve la clé à partir du moment où
il sait que le clair était une image JPEG. Cette seule info suffit à
permettre une attaque réussie.
...
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors
là, oui, on peut faire quelque chose.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Salut !Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de
l'algo et du chiffré 6-16-19-13-31-21 ? "
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la clé
à partir du chiffré seul, mais trouve la clé à partir du moment où il sait
que le clair était une image JPEG. Cette seule info suffit à permettre une
attaque réussie.
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Cette question montre bien votre méconaissance des méthodes utilisées pour
faire sauter votre système. Donner 48bits d'infos et dire : "quel est le
clair ?", c'est exactement le même que si vous nous demandiez quels sont a
et b donnant a+b = 60.
On a quelques infos permettant de simplifier le problème, mais pas assez
pour donner un verdict précis.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
Il y a de l'information : les caractères de la clé de session ne couvrent
pas [0-255] entièrement,
et quelques octets du clair sont connus ou du moins sont trouvables en
cherchant un peu.
Si du texte a été chiffré, alors on a des infos sur les plages de valeurs
utilisées, et les fréquences de caractères selon les langues.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Salut !
Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de
l'algo et du chiffré 6-16-19-13-31-21 ? "
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la clé
à partir du chiffré seul, mais trouve la clé à partir du moment où il sait
que le clair était une image JPEG. Cette seule info suffit à permettre une
attaque réussie.
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Cette question montre bien votre méconaissance des méthodes utilisées pour
faire sauter votre système. Donner 48bits d'infos et dire : "quel est le
clair ?", c'est exactement le même que si vous nous demandiez quels sont a
et b donnant a+b = 60.
On a quelques infos permettant de simplifier le problème, mais pas assez
pour donner un verdict précis.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
Il y a de l'information : les caractères de la clé de session ne couvrent
pas [0-255] entièrement,
et quelques octets du clair sont connus ou du moins sont trouvables en
cherchant un peu.
Si du texte a été chiffré, alors on a des infos sur les plages de valeurs
utilisées, et les fréquences de caractères selon les langues.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Salut !Non non. Vous n'avez pas cassé l'algo :-)
Relisez bien ma question:
La question était: " 'Pouvons-nous trouver le clair à partir de
l'algo et du chiffré 6-16-19-13-31-21 ? "
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Avec uniquement du bruit blanc en entrée de l'algo il n'est pas
extrêmement simple de trouver la clé utilisée, mais avec juste quelques
infos éparses on y arrive très facilement.
J'ai fais un programme d'une trentaine de lignes, qui ne trouve pas la clé
à partir du chiffré seul, mais trouve la clé à partir du moment où il sait
que le clair était une image JPEG. Cette seule info suffit à permettre une
attaque réussie.
Si vous désirez refaire le teste, je vous redonne le chiffré
225-111-037-088-088-057 suivant à partir duquel vous pouvez essayer de
trouver le clair avec l'aide de l'algo seulement?
Cette question montre bien votre méconaissance des méthodes utilisées pour
faire sauter votre système. Donner 48bits d'infos et dire : "quel est le
clair ?", c'est exactement le même que si vous nous demandiez quels sont a
et b donnant a+b = 60.
On a quelques infos permettant de simplifier le problème, mais pas assez
pour donner un verdict précis.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
Il y a de l'information : les caractères de la clé de session ne couvrent
pas [0-255] entièrement,
et quelques octets du clair sont connus ou du moins sont trouvables en
cherchant un peu.
Si du texte a été chiffré, alors on a des infos sur les plages de valeurs
utilisées, et les fréquences de caractères selon les langues.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
Dans la version actuelle avec les rotations, je pense que tu as affaibli
ton algorithme et qu'il doit être possible de sélectionner des clairs
possibles correpondant à un chiffré. Il est probable qu'avec un chiffré
suffisament long et avec des renseignements sur la nature du fichier, il
est faisable de trouver le clair sans la clé.
Cependant, cela dépasse mes capacités/compétences de bénévole à
être compris.
Je reste donc toujours sur les attaques à clair connu. Ce ne sont pas
des futilités théoriques : imagine que tu m'envoies un fichier chiffré
avec ton procédé. Tu me communiquera la clé pour le déchiffrer. Je le
déchiffrerai, c'est fait pour. A partir de là, j'aurai le clair et le
chiffré, donc la clé, donc ta clé. De là, si tu utilises toujours la
même clé (ce qui est une utilisation normale) je pourrai déchiffrer les
messages chiffrés chez d'autres correspondants, et vice-versa. Cette
vulnérabilité suffit à invalider ton procédé, voilà pourquoi je ne
considère pas utile de tenter la cryptanalyse.
J'ai transmis l'état de mes recherches et le programme en C servant à
trouver cette clé dans l'article : <csiovk$2q71$
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
Dans la version actuelle avec les rotations, je pense que tu as affaibli
ton algorithme et qu'il doit être possible de sélectionner des clairs
possibles correpondant à un chiffré. Il est probable qu'avec un chiffré
suffisament long et avec des renseignements sur la nature du fichier, il
est faisable de trouver le clair sans la clé.
Cependant, cela dépasse mes capacités/compétences de bénévole à
être compris.
Je reste donc toujours sur les attaques à clair connu. Ce ne sont pas
des futilités théoriques : imagine que tu m'envoies un fichier chiffré
avec ton procédé. Tu me communiquera la clé pour le déchiffrer. Je le
déchiffrerai, c'est fait pour. A partir de là, j'aurai le clair et le
chiffré, donc la clé, donc ta clé. De là, si tu utilises toujours la
même clé (ce qui est une utilisation normale) je pourrai déchiffrer les
messages chiffrés chez d'autres correspondants, et vice-versa. Cette
vulnérabilité suffit à invalider ton procédé, voilà pourquoi je ne
considère pas utile de tenter la cryptanalyse.
J'ai transmis l'état de mes recherches et le programme en C servant à
trouver cette clé dans l'article : <csiovk$2q71$1@biggoron.nerim.net>
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
Dans la version actuelle avec les rotations, je pense que tu as affaibli
ton algorithme et qu'il doit être possible de sélectionner des clairs
possibles correpondant à un chiffré. Il est probable qu'avec un chiffré
suffisament long et avec des renseignements sur la nature du fichier, il
est faisable de trouver le clair sans la clé.
Cependant, cela dépasse mes capacités/compétences de bénévole à
être compris.
Je reste donc toujours sur les attaques à clair connu. Ce ne sont pas
des futilités théoriques : imagine que tu m'envoies un fichier chiffré
avec ton procédé. Tu me communiquera la clé pour le déchiffrer. Je le
déchiffrerai, c'est fait pour. A partir de là, j'aurai le clair et le
chiffré, donc la clé, donc ta clé. De là, si tu utilises toujours la
même clé (ce qui est une utilisation normale) je pourrai déchiffrer les
messages chiffrés chez d'autres correspondants, et vice-versa. Cette
vulnérabilité suffit à invalider ton procédé, voilà pourquoi je ne
considère pas utile de tenter la cryptanalyse.
J'ai transmis l'état de mes recherches et le programme en C servant à
trouver cette clé dans l'article : <csiovk$2q71$
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
