Je vais vous donner ici un petit problème qu'on retrouve seulement en
partie dans AllCrypter.
Si vous ne trouvez pas que cette façon de faire soit passablement sûr, alors
je vous demanderais de nous détailler au moins un petit exemple pour le
démontrer. Donc, je suis prêt à prendre vos conseils si vous pensez que ce
petit exemple simplifié ne vaut rien.
Voici l'exemple (ici je ne fais que des additions et ne fais pas de Xor
ni de Modulo comme il y a dans la version 3 dont je veux mettre les calculs
sur Internet après sa sortie):
Clef en clair: 12 ( en ascii = 49 50)
Texte à crypter: 345 (en ascii = 51 52 53)
J'aligne donc pour plus de clarté:
12 = clef
345 = texte à chiffrer
ou en ascii:
49-50
51-52-53
On crypte le caractère 3 (ascii 51) en faisant 49+51+52=152
On crypte le caractère 4 (ascii 52) en faisant 50+52+53=155
On crypte le caractère 5 (ascii 53) en faisant 49+53+49=151
Le texte crypté (en ascii pour mieux voir) donnerait 152 155 151
Et si on a:
155 = clef
251= texte à chiffrer
ou en ascii:
49-53-53
50-53-49
On crypte le 1er caractère (ascii 50) en faisant 49+50+53=152
On crypte le 2e caractère (ascii 53) en faisant 53+53+49=155
On crypte le 3e caractère (ascii 49) en faisant 53+49+49=151
Le texte crypté (en ascii pour mieux voir) serait identique au précédent 152
155 151
La question est: "Est-il possible de décrypter ces trois caractères
(ascii= 152-155-151) avec ce simple petit algorithme sans connaître la clef
?"
Dans cette seule condition, je pense que 'non' et je pense que c'est
même impossible. Et pourtant un enfant de 10 ans pourrait crypter de cette
façon.
Car en faisant l'inverse, il faudrait deviner le premier caractère de la
clef et deviner le dernier caractère non crypté du chiffré. Alors comment
pourrait-on trouver l'avant dernier caractère si on n'a pas trouvé le
dernier caractère? Et comment trouver le premier caractère si on n'a pas
trouvé le 2e caractère? Il vous serait peut-être plus difficile de
déchiffrer le cryptogramme de cette façon que d'essayer toutes les clefs
possibles à l'endroit où on tape la clef dans le logiciel.
Certaines personnes n'additionnent que chaque caractère de la clef avec
le caractère actuel (non crypté) du texte à crypter. Cette façon de faire
ne donne rien puisqu'en cryptant des caractères NUL (c'est à dire, ascii
zéro) on lira très clairement la clef qui se répète dans le chiffré.
Les caractères zéro peuvent se trouver dans un fichier '.mov' ou '.jpg'
par exemple. Après avoir pris connaissance de la clef dans le chiffré il
suffirait alors d'écrire cette clef pour décrypter le tout. Car ceci
donnerait:
Clef en clair: 12 (en ascii = 49 50)
Texte à crypter: (en ascii= 0 0 0)
En cryptant le caractère Nul (ascii 0) on fait 49+0=49
En cryptant le caractère Nul (ascii 0) on fait 50+0=50
En cryptant le caractère Nul (ascii 0) on fait 49+0=49
Le texte crypté donnerait la clef elle-même en clair = (en ascii) 49 50 49
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est exactement le même genre de calcul que xor, sauf que la barre est plus haute.
Au final, on a fait : 12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Et c'est précisément le type de problèmes que l'on trouve dans les algorithmes utilisés par le logiciel de R.H. Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Codialement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !" Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Salut !
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est
exactement le même genre de calcul que xor, sauf que la barre est plus
haute.
Au final, on a fait :
12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Et c'est précisément le type de problèmes que l'on trouve dans les
algorithmes utilisés par le logiciel de R.H.
Il est possible d'annuler la clé et donc l'attaque par clair connu est
extrêmement simple, et va permettre de déchiffrer sans la clé.
Codialement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est exactement le même genre de calcul que xor, sauf que la barre est plus haute.
Au final, on a fait : 12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Et c'est précisément le type de problèmes que l'on trouve dans les algorithmes utilisés par le logiciel de R.H. Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Codialement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !" Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Jean-Marc Desperrier
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est
extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de
façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des
extensions à clair connu existent.
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
Christophe HENRY
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
J'ai essayé de trouver des clairs qui provoqueraient la sortie de la clé en guise de chiffré. En fait, ce n'est pas possible puisque mes calculs nécessitent la connaissance de la clé :-/
Il suffit simplement de connaître le clair, choisi ou non. Avec le clair et le chiffré on trouve de manière rigoureusement unique la clé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est
extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de
façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des
extensions à clair connu existent.
J'ai essayé de trouver des clairs qui provoqueraient la sortie de la clé
en guise de chiffré. En fait, ce n'est pas possible puisque mes calculs
nécessitent la connaissance de la clé :-/
Il suffit simplement de connaître le clair, choisi ou non. Avec le clair
et le chiffré on trouve de manière rigoureusement unique la clé.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
J'ai essayé de trouver des clairs qui provoqueraient la sortie de la clé en guise de chiffré. En fait, ce n'est pas possible puisque mes calculs nécessitent la connaissance de la clé :-/
Il suffit simplement de connaître le clair, choisi ou non. Avec le clair et le chiffré on trouve de manière rigoureusement unique la clé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
AMcD®
Christophe HENRY wrote:
Il suffit simplement de connaître le clair, choisi ou non. Avec le clair et le chiffré on trouve de manière rigoureusement unique la clé.
Vous vous tracassez pour pas grand chose les amis. Je parie qu'on n'aura pas besoin d'attaquer avec quoi que ce soit pour obtenir/déchiffrer la clé, et ce quelle que soit la version :-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Christophe HENRY wrote:
Il suffit simplement de connaître le clair, choisi ou non. Avec le
clair et le chiffré on trouve de manière rigoureusement unique la clé.
Vous vous tracassez pour pas grand chose les amis. Je parie qu'on n'aura pas
besoin d'attaquer avec quoi que ce soit pour obtenir/déchiffrer la clé, et
ce quelle que soit la version :-).
Il suffit simplement de connaître le clair, choisi ou non. Avec le clair et le chiffré on trouve de manière rigoureusement unique la clé.
Vous vous tracassez pour pas grand chose les amis. Je parie qu'on n'aura pas besoin d'attaquer avec quoi que ce soit pour obtenir/déchiffrer la clé, et ce quelle que soit la version :-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Mister Jack
Salut !
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant le résultat... Je préviens, je fais long pour être sûr que tout le monde suive...
Le système de "codage" employé semble être en deux phases (pour le niveau 1) : - Bidouillage sommaire du clair ; - Ajout d'une couche calculée à partir de la clé.
On va prendre 3 messages pour la démonstration : clair1, chiffré1 et chiffré2 (je crois que c'est clair :D). Le but est de retrouver clair2 sans la clé.
Pour le chiffré on a : chiffré = clair_bidouillé + cle_bidouillée
Suffit de faire chiffré2-chiffré1 (bit à bit) pour obtenir clair2_bidouillé + cle_bidouillée - clair1_bidouillé - cle_bidouillée = clair2_bidouillé - clair1_bidouillé
on passe de clair à clair_bidouillé par clair : c0,c1,c2,...,cn clair_bidouillé : c0+c1, c1+c2, ... cn-1+cn, cn
donc à partir de clair1, on calcule clair1_bidouillé et avec chiffré2-chiffré1+clair1_bidouillé on obtient le clair2_bidouillé.
Comme il y a un effet de bord intéressant (dernier octet), il suffit, pour chaque octet en partant de l'avant-dernier, de lui soustraire la valeur de l'octet suivant, et on obtient le clair2.
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même retrouvé le clair d'un message...
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
Amicalement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !" Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Salut !
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est
extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de
façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des
extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant
le résultat...
Je préviens, je fais long pour être sûr que tout le monde suive...
Le système de "codage" employé semble être en deux phases (pour le
niveau 1) :
- Bidouillage sommaire du clair ;
- Ajout d'une couche calculée à partir de la clé.
On va prendre 3 messages pour la démonstration : clair1, chiffré1 et
chiffré2 (je crois que c'est clair :D). Le but est de retrouver clair2
sans la clé.
Pour le chiffré on a : chiffré = clair_bidouillé + cle_bidouillée
Suffit de faire chiffré2-chiffré1 (bit à bit) pour obtenir
clair2_bidouillé + cle_bidouillée - clair1_bidouillé - cle_bidouillée =
clair2_bidouillé - clair1_bidouillé
on passe de clair à clair_bidouillé par
clair : c0,c1,c2,...,cn
clair_bidouillé : c0+c1, c1+c2, ... cn-1+cn, cn
donc à partir de clair1, on calcule clair1_bidouillé
et avec chiffré2-chiffré1+clair1_bidouillé on obtient le clair2_bidouillé.
Comme il y a un effet de bord intéressant (dernier octet), il suffit,
pour chaque octet en partant de l'avant-dernier, de lui soustraire la
valeur de l'octet suivant, et on obtient le clair2.
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même
retrouvé le clair d'un message...
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais
c'est facilement transposable. De même, il est facile de trouver la clé,
comme l'a souligné Christophe Henry. L'intérêt de cette méthode est
d'être indépendante de la longueur de la clé.
Je pensais filer le programme pour faire une démonstration, mais je
crois que c'est même pas nécessaire, là...
Amicalement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant le résultat... Je préviens, je fais long pour être sûr que tout le monde suive...
Le système de "codage" employé semble être en deux phases (pour le niveau 1) : - Bidouillage sommaire du clair ; - Ajout d'une couche calculée à partir de la clé.
On va prendre 3 messages pour la démonstration : clair1, chiffré1 et chiffré2 (je crois que c'est clair :D). Le but est de retrouver clair2 sans la clé.
Pour le chiffré on a : chiffré = clair_bidouillé + cle_bidouillée
Suffit de faire chiffré2-chiffré1 (bit à bit) pour obtenir clair2_bidouillé + cle_bidouillée - clair1_bidouillé - cle_bidouillée = clair2_bidouillé - clair1_bidouillé
on passe de clair à clair_bidouillé par clair : c0,c1,c2,...,cn clair_bidouillé : c0+c1, c1+c2, ... cn-1+cn, cn
donc à partir de clair1, on calcule clair1_bidouillé et avec chiffré2-chiffré1+clair1_bidouillé on obtient le clair2_bidouillé.
Comme il y a un effet de bord intéressant (dernier octet), il suffit, pour chaque octet en partant de l'avant-dernier, de lui soustraire la valeur de l'octet suivant, et on obtient le clair2.
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même retrouvé le clair d'un message...
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
Amicalement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !" Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/
Raymond H.
"Christophe HENRY" a écrit dans le message de news: crdtmc$26mm$
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X, X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne désigne pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la table des caractères.
En fait, si tu regardes les calculs tu notes que les valeurs d'un chiffré sont toujours supérieure de celles du clair. Il n'y a que des additions, pour le moment. Il faut bien repasser en-dessous de 255 à un moment ou à un autre. Introduire des soustractions risque d'aboutir à des résultats négatifs.
Dans un cas comme dans l'autre, il faut couper ce qui dépasse : l'arithmétique modulaire intervient. Le xor en est l'exemple canonique puisqu'il s'agit d'une addition dont le résultat est ramené à une valeur inférieur à 2 dès qu'on la dépasse.
Je ne vois toujours pas le rapport avec un XOR. Car dans notre exemple, il est vrai que les valeurs n'ont pas encore dépassées 255 et si ça aurait été le cas j'aurais expliqué que nous devons utiliser le modulo et non le xor qui lui n'a aucun rapport avec le reste.
Donc, si on dépasse 255 il est très évident de faire "Valeur Modulo 256". Cela va de soit et je ne pensais pas qu'il ait été nécessaire de l'expliquer prématurément, mais bon :-)
Or, le XOR est hors contexte dans notre exemple. Mais comme vous dites, en améliorant l'exemple, on pourrait sûrement à l'ajouter éventuellement et le calculer dans l'une des étapes de calcul où cela est possible.
Erwann a juste pris de l'avance.
Le XOR se calcul à partir des bits (en binaire) et non à partir des caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y a pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On préssent qu'il va forcément en avoir, pour les raisons indiquées plus haut.
Tout à fait d'accord.
On compare notre exemple avec le XOR seulement en rapport avec le fait qu'il est aussi difficile que le XOR à déchiffrer (sinon impossible) et le résultat des données eux-mêmes n'équivaut pas le XOR non plus.
Pas tout à fait. Ton calcul est bien plus proche du xor (à mon humble avis) que tu ne l'entends. C'est juste que nous n'avons pas parlé de modulo pour le moment. Erwan (et les autres spécialistes), moi-même et les matrices t'y attendons de pied ferme :-)
:-)
L'utilisation du symbole plus est tout à fait pertinente pour parler du xor.
Ha bon! :) Habituellement on fait "ValeurA Xor ValeurB" et non + car le XOR n'est pas une addition.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 + M2 Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
Lorsque le valeur du chiffré C devient non stockable dans un octet, comment feras-tu ? Tu couperas à 255, en soustrayant 256 autant de fois que nécessaire pour repasser en-dessous.
On chiffre : M = 12 K = 128 C = 12 + 128 = 140
On inverse, en surchiffrant : C = 140 K = 128 M = 140 + 128 = 12
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est exactement le même genre de calcul que xor, sauf que la barre est plus haute.
Permettez-moi d'insister gentiment. Ce n'est pas le même genre de calcul que le XOR et cela n'a rien en commun.
Comme en programmation, on fait ça en une seule passe avec le "modulo 256" (puisque de 0 à 255 = 256).
1er exemple : avec la calculatrice scientifique de Windows on fait 275 Mod 256 = 19 ; donc le Xor n'a pas sa place ici puisque le Xor ne fait que des comparaisons de chiffres binaires en base 2.
2e exemple : 2546 Mod 256 = 242
On vérifie à la main en faisant 256 * 9 = 2304 (puisque 2546 divisé par 256 donne 9,9453125), donc 2546 - 2304 = 242 comme reste.
Pour décrypter on fait l'inverse:
242 - 2304 = 2062
(-2062) Mod 256 = -14 donc -14 + 256 = 242 comme reste. Donc ((-2062) Mod 256) + 256 = 242 .
Au final, on a fait : 12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Je suis d'accord avec vous pour la réadaptation à l'intérieur des paramètres de la base 256. Mais, dans notre calcul on ne peut pas faire d'annulation en Xor car on n'a pas à utiliser de XOR puisque les donnée sont calculées en décimal puis reconverties en base 256 si nécessaire, sinon cela ne serait pas compatible. Le XOR n'a donc pas sa place dans ce calcul et ne peut pas non plus être utilisé dans cette étape-ci du calcul du 'Simple algo'.
Cordialement :-)
Raymond H.
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: crdtmc$26mm$1@biggoron.nerim.net...
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne
désigne
pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la
table
des caractères.
En fait, si tu regardes les calculs tu notes que les valeurs d'un
chiffré sont toujours supérieure de celles du clair. Il n'y a que des
additions, pour le moment. Il faut bien repasser en-dessous de 255 à un
moment ou à un autre. Introduire des soustractions risque d'aboutir à
des résultats négatifs.
Dans un cas comme dans l'autre, il faut couper ce qui dépasse :
l'arithmétique modulaire intervient. Le xor en est l'exemple canonique
puisqu'il s'agit d'une addition dont le résultat est ramené à une
valeur inférieur à 2 dès qu'on la dépasse.
Je ne vois toujours pas le rapport avec un XOR. Car dans notre exemple,
il est vrai que les valeurs n'ont pas encore dépassées 255 et si ça aurait
été le cas j'aurais expliqué que nous devons utiliser le modulo et non le
xor qui lui n'a aucun rapport avec le reste.
Donc, si on dépasse 255 il est très évident de faire "Valeur Modulo
256". Cela va de soit et je ne pensais pas qu'il ait été nécessaire de
l'expliquer prématurément, mais bon :-)
Or, le XOR est hors contexte dans notre exemple. Mais comme vous dites, en
améliorant l'exemple, on pourrait sûrement à l'ajouter éventuellement et le
calculer dans l'une des étapes de calcul où cela est possible.
Erwann a juste pris de l'avance.
Le XOR se calcul à partir des bits (en binaire) et non à partir des
caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y
a
pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On préssent qu'il va forcément en avoir, pour les raisons indiquées plus
haut.
Tout à fait d'accord.
On compare
notre exemple avec le XOR seulement en rapport avec le fait qu'il est
aussi
difficile que le XOR à déchiffrer (sinon impossible) et le résultat des
données eux-mêmes n'équivaut pas le XOR non plus.
Pas tout à fait. Ton calcul est bien plus proche du xor (à mon humble
avis) que tu ne l'entends. C'est juste que nous n'avons pas parlé de
modulo pour le moment. Erwan (et les autres spécialistes), moi-même et
les matrices t'y attendons de pied ferme :-)
:-)
L'utilisation du symbole plus est tout à fait pertinente pour parler du
xor.
Ha bon! :) Habituellement on fait "ValeurA Xor ValeurB" et non + car le XOR
n'est pas une addition.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 +
M2
Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
Lorsque le valeur du chiffré C devient non stockable dans un octet,
comment feras-tu ? Tu couperas à 255, en soustrayant 256 autant de fois
que nécessaire pour repasser en-dessous.
On chiffre :
M = 12
K = 128
C = 12 + 128 = 140
On inverse, en surchiffrant :
C = 140
K = 128
M = 140 + 128 = 12
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est
exactement le même genre de calcul que xor, sauf que la barre est plus
haute.
Permettez-moi d'insister gentiment. Ce n'est pas le même genre de calcul
que le XOR et cela n'a rien en commun.
Comme en programmation, on fait ça en une seule passe avec le "modulo
256" (puisque de 0 à 255 = 256).
1er exemple : avec la calculatrice scientifique de Windows on fait 275 Mod
256 = 19 ; donc le Xor n'a pas sa place ici puisque le Xor ne fait que des
comparaisons de chiffres binaires en base 2.
2e exemple : 2546 Mod 256 = 242
On vérifie à la main en faisant 256 * 9 = 2304 (puisque 2546 divisé par 256
donne 9,9453125), donc 2546 - 2304 = 242 comme reste.
Pour décrypter on fait l'inverse:
242 - 2304 = 2062
(-2062) Mod 256 = -14 donc -14 + 256 = 242 comme reste. Donc ((-2062) Mod
256) + 256 = 242 .
Au final, on a fait :
12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Je suis d'accord avec vous pour la réadaptation à l'intérieur des
paramètres de la base 256. Mais, dans notre calcul on ne peut pas faire
d'annulation en Xor car on n'a pas à utiliser de XOR puisque les donnée sont
calculées en décimal puis reconverties en base 256 si nécessaire, sinon cela
ne serait pas compatible. Le XOR n'a donc pas sa place dans ce calcul et ne
peut pas non plus être utilisé dans cette étape-ci du calcul du 'Simple
algo'.
"Christophe HENRY" a écrit dans le message de news: crdtmc$26mm$
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X, X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne désigne pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la table des caractères.
En fait, si tu regardes les calculs tu notes que les valeurs d'un chiffré sont toujours supérieure de celles du clair. Il n'y a que des additions, pour le moment. Il faut bien repasser en-dessous de 255 à un moment ou à un autre. Introduire des soustractions risque d'aboutir à des résultats négatifs.
Dans un cas comme dans l'autre, il faut couper ce qui dépasse : l'arithmétique modulaire intervient. Le xor en est l'exemple canonique puisqu'il s'agit d'une addition dont le résultat est ramené à une valeur inférieur à 2 dès qu'on la dépasse.
Je ne vois toujours pas le rapport avec un XOR. Car dans notre exemple, il est vrai que les valeurs n'ont pas encore dépassées 255 et si ça aurait été le cas j'aurais expliqué que nous devons utiliser le modulo et non le xor qui lui n'a aucun rapport avec le reste.
Donc, si on dépasse 255 il est très évident de faire "Valeur Modulo 256". Cela va de soit et je ne pensais pas qu'il ait été nécessaire de l'expliquer prématurément, mais bon :-)
Or, le XOR est hors contexte dans notre exemple. Mais comme vous dites, en améliorant l'exemple, on pourrait sûrement à l'ajouter éventuellement et le calculer dans l'une des étapes de calcul où cela est possible.
Erwann a juste pris de l'avance.
Le XOR se calcul à partir des bits (en binaire) et non à partir des caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y a pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On préssent qu'il va forcément en avoir, pour les raisons indiquées plus haut.
Tout à fait d'accord.
On compare notre exemple avec le XOR seulement en rapport avec le fait qu'il est aussi difficile que le XOR à déchiffrer (sinon impossible) et le résultat des données eux-mêmes n'équivaut pas le XOR non plus.
Pas tout à fait. Ton calcul est bien plus proche du xor (à mon humble avis) que tu ne l'entends. C'est juste que nous n'avons pas parlé de modulo pour le moment. Erwan (et les autres spécialistes), moi-même et les matrices t'y attendons de pied ferme :-)
:-)
L'utilisation du symbole plus est tout à fait pertinente pour parler du xor.
Ha bon! :) Habituellement on fait "ValeurA Xor ValeurB" et non + car le XOR n'est pas une addition.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 + M2 Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
Lorsque le valeur du chiffré C devient non stockable dans un octet, comment feras-tu ? Tu couperas à 255, en soustrayant 256 autant de fois que nécessaire pour repasser en-dessous.
On chiffre : M = 12 K = 128 C = 12 + 128 = 140
On inverse, en surchiffrant : C = 140 K = 128 M = 140 + 128 = 12
Nous étions arrivés à 268, auquel nous avons soustrait 256, C'est exactement le même genre de calcul que xor, sauf que la barre est plus haute.
Permettez-moi d'insister gentiment. Ce n'est pas le même genre de calcul que le XOR et cela n'a rien en commun.
Comme en programmation, on fait ça en une seule passe avec le "modulo 256" (puisque de 0 à 255 = 256).
1er exemple : avec la calculatrice scientifique de Windows on fait 275 Mod 256 = 19 ; donc le Xor n'a pas sa place ici puisque le Xor ne fait que des comparaisons de chiffres binaires en base 2.
2e exemple : 2546 Mod 256 = 242
On vérifie à la main en faisant 256 * 9 = 2304 (puisque 2546 divisé par 256 donne 9,9453125), donc 2546 - 2304 = 242 comme reste.
Pour décrypter on fait l'inverse:
242 - 2304 = 2062
(-2062) Mod 256 = -14 donc -14 + 256 = 242 comme reste. Donc ((-2062) Mod 256) + 256 = 242 .
Au final, on a fait : 12 +128 +128 = 12
C'est un cas simple d'annulation de la clé.
Je suis d'accord avec vous pour la réadaptation à l'intérieur des paramètres de la base 256. Mais, dans notre calcul on ne peut pas faire d'annulation en Xor car on n'a pas à utiliser de XOR puisque les donnée sont calculées en décimal puis reconverties en base 256 si nécessaire, sinon cela ne serait pas compatible. Le XOR n'a donc pas sa place dans ce calcul et ne peut pas non plus être utilisé dans cette étape-ci du calcul du 'Simple algo'.
Cordialement :-)
Raymond H.
Raymond H.
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'. Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement. Et si c'est le cas, il suffirait de remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3 à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite. Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
Bonne soirée.
Raymond H.
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais
c'est facilement transposable. De même, il est facile de trouver la clé,
comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être
indépendante de la longueur de la clé.
Je pensais filer le programme pour faire une démonstration, mais je crois
que c'est même pas nécessaire, là...
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la
clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au
cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite
continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour
trouver la clef dans notre petit exemple 'Simple algo'. Je vais vérifier,
via l'algèbre, si c'est aussi possible pour trouver le clair à partir de
l'algo et du chiffré uniquement. Et si c'est le cas, il suffirait de
remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui
favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre
message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour
mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3
à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite.
Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense
que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'. Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement. Et si c'est le cas, il suffirait de remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3 à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite. Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
Bonne soirée.
Raymond H.
Christophe HENRY
Salut !
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant le résultat... Je préviens, je fais long pour être sûr que tout le monde suive...
Je fais court, histoire de te contrarier ;-)
Soient les variables suivantes : M1 = le premier clair connu. M2 = le deuxième clair *inconnu* C1 = le chiffré de M1, connu. C2 = le chiffré de M2, *connu*
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même retrouvé le clair d'un message...
Pareil :-)
Le fait que la clé est bidouillée rend l'algorithme plus obscur mais pas plus complexe :
Soit la simple formule, de l'éponyme algorithme : C = Mm*M + Mk*K M et K sont respectivement le clair et la clé. C est le chiffré. Mm et Mk sont deux matrices traduisant les fameuses "bidouilles".
Le problème se pose selon le système d'équation matriciel suivant : (1) C1 = Mm*M1 + Mk*K (2) C2 = Mm*M2 + Mk*K
Avec C1, C2 et M1, M2 les chiffrés et les clairs. K est le même pour les deux calculs.
Donc, le deuxième clair s'exprime en fonction des chiffrés C1, C2 et du premier clair M1 :
M2 = inv(Mm)*(C2-C1+Mm*M1)
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
J'admire ton courage, parce que je n'ai pas résisté :-o Oui, oui, c'est bien le code de trois lignes en scilab.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Salut !
Mister Jack wrote:
Il est possible d'annuler la clé et donc l'attaque par clair connu est
extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de
façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des
extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant
le résultat...
Je préviens, je fais long pour être sûr que tout le monde suive...
Je fais court, histoire de te contrarier ;-)
Soient les variables suivantes :
M1 = le premier clair connu.
M2 = le deuxième clair *inconnu*
C1 = le chiffré de M1, connu.
C2 = le chiffré de M2, *connu*
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même
retrouvé le clair d'un message...
Pareil :-)
Le fait que la clé est bidouillée rend l'algorithme plus obscur mais pas
plus complexe :
Soit la simple formule, de l'éponyme algorithme : C = Mm*M + Mk*K
M et K sont respectivement le clair et la clé. C est le chiffré.
Mm et Mk sont deux matrices traduisant les fameuses "bidouilles".
Le problème se pose selon le système d'équation matriciel suivant :
(1) C1 = Mm*M1 + Mk*K
(2) C2 = Mm*M2 + Mk*K
Avec C1, C2 et M1, M2 les chiffrés et les clairs. K est le même pour les
deux calculs.
Donc, le deuxième clair s'exprime en fonction des chiffrés C1, C2 et du
premier clair M1 :
M2 = inv(Mm)*(C2-C1+Mm*M1)
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais
c'est facilement transposable. De même, il est facile de trouver la clé,
comme l'a souligné Christophe Henry. L'intérêt de cette méthode est
d'être indépendante de la longueur de la clé.
Je pensais filer le programme pour faire une démonstration, mais je
crois que c'est même pas nécessaire, là...
J'admire ton courage, parce que je n'ai pas résisté :-o Oui, oui, c'est
bien le code de trois lignes en scilab.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Il est possible d'annuler la clé et donc l'attaque par clair connu est extrêmement simple, et va permettre de déchiffrer sans la clé.
Ca ne serait pas plutôt une attaque par clair choisi, car choisi de façon à annuler la clé ? Bien sûr, il est possible qu'ensuite des extensions à clair connu existent.
C'est bien à clair connu... et j'ai failli m'écrouler de rire en voyant le résultat... Je préviens, je fais long pour être sûr que tout le monde suive...
Je fais court, histoire de te contrarier ;-)
Soient les variables suivantes : M1 = le premier clair connu. M2 = le deuxième clair *inconnu* C1 = le chiffré de M1, connu. C2 = le chiffré de M2, *connu*
La clé n'apparait nulle part (ni en clair, ni codée), et on a quand même retrouvé le clair d'un message...
Pareil :-)
Le fait que la clé est bidouillée rend l'algorithme plus obscur mais pas plus complexe :
Soit la simple formule, de l'éponyme algorithme : C = Mm*M + Mk*K M et K sont respectivement le clair et la clé. C est le chiffré. Mm et Mk sont deux matrices traduisant les fameuses "bidouilles".
Le problème se pose selon le système d'équation matriciel suivant : (1) C1 = Mm*M1 + Mk*K (2) C2 = Mm*M2 + Mk*K
Avec C1, C2 et M1, M2 les chiffrés et les clairs. K est le même pour les deux calculs.
Donc, le deuxième clair s'exprime en fonction des chiffrés C1, C2 et du premier clair M1 :
M2 = inv(Mm)*(C2-C1+Mm*M1)
OK, ça marche tel quel uniquement avec 2 messages de même longueur. Mais c'est facilement transposable. De même, il est facile de trouver la clé, comme l'a souligné Christophe Henry. L'intérêt de cette méthode est d'être indépendante de la longueur de la clé. Je pensais filer le programme pour faire une démonstration, mais je crois que c'est même pas nécessaire, là...
J'admire ton courage, parce que je n'ai pas résisté :-o Oui, oui, c'est bien le code de trois lignes en scilab.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Christophe HENRY
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses propriétés algébriques (xor, oui, je sais, mais bon...) font que la clé est (linéairement) dépendante du clair et du chiffré.
Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Et si c'est le cas, il suffirait de remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Ca change un _seul_ caractère dans les calculs matriciels.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3 à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite.
Je pense que c'est inutile. A la vue de mes lectures des mois précédents, les lecteurs intéressés ont le niveau requis pour lire les calculs matriciels. Par ailleurs, les résultats de mes calculs montrent bien qu'il ne s'agit pas que de théories.
Partant de là, s'il est montré qu'il existe une exception au blindage du simple algo alors tout l'algo est à revoir. Je me charge de trouver toutes les exceptions.
Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
Aucune chance.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la
clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au
cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite
continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour
trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses
propriétés algébriques (xor, oui, je sais, mais bon...) font que la
clé est (linéairement) dépendante du clair et du chiffré.
Je vais vérifier,
via l'algèbre, si c'est aussi possible pour trouver le clair à partir de
l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et
les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Et si c'est le cas, il suffirait de
remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui
favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Ca change un _seul_ caractère dans les calculs matriciels.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre
message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour
mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3
à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite.
Je pense que c'est inutile. A la vue de mes lectures des
mois précédents, les lecteurs intéressés ont le niveau requis pour
lire les calculs matriciels. Par ailleurs, les résultats de mes calculs
montrent bien qu'il ne s'agit pas que de théories.
Partant de là, s'il est montré qu'il existe une exception au blindage du
simple algo alors tout l'algo est à revoir. Je me charge de trouver
toutes les exceptions.
Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense
que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
Aucune chance.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses propriétés algébriques (xor, oui, je sais, mais bon...) font que la clé est (linéairement) dépendante du clair et du chiffré.
Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Et si c'est le cas, il suffirait de remplacer k1 par k4 dans notre petit exemple afin de couper le cycle qui favoriserait ce genre de calcul pour trouver la clef via l'algèbre.
Ca change un _seul_ caractère dans les calculs matriciels.
Lorsque j'aurai plus de temps je veux mettre, à la suite d'un autre message déjà écrit dans ce fil, le calcul d'algèbre fait à la main pour mieux expliquer pourquoi c'est possible via le renouvellement du cycle de k3 à k1 pour continuer de k1 à k2, de k2 à k3, de k3 à k1 et ainsi de suite.
Je pense que c'est inutile. A la vue de mes lectures des mois précédents, les lecteurs intéressés ont le niveau requis pour lire les calculs matriciels. Par ailleurs, les résultats de mes calculs montrent bien qu'il ne s'agit pas que de théories.
Partant de là, s'il est montré qu'il existe une exception au blindage du simple algo alors tout l'algo est à revoir. Je me charge de trouver toutes les exceptions.
Car en coupant de k3 à k1 cela couperait le cycle et du même coup je pense que ça empêcherait l'algèbre pour trouver la clef (c'est à vérifier).
Aucune chance.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Raymond H.
"Christophe HENRY" a écrit dans le message de news: crfckb$2tgs$
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses propriétés algébriques (xor, oui, je sais, mais bon...) font que la clé est (linéairement) dépendante du clair et du chiffré.
Disons que je ne suis pas tout à fait d'accord. Je dirais plutôt que si chaque caractère de la clef dépend au moins de deux autres caractères de la clef alors là c'est possible (dans notre exemple), mais si un seul caractère ne dépend plus de deux autres caractères de la clef alors là se serait impossible dans notre exemple.
Exemple: si k2 est dépendant de k3 pour M2 et est aussi dépendant de k1 pour M1 alors là on peut trouver la clef puisque tous les caractères sont en relation avec un caractère qui le précèdent et un autre caractères qui le suit (comme si on attacherait le début avec la fin et ainsi créer une roue qui tourne et dont tous les engrenages dépendent les uns des autres). Du moins c'est ce que je pense pour notre exemple. Vous pourriez vérifier avec l'exemple que je mets dans le message en question dans ce fil et où je vais mettre le calcul algébrique qui trouve la clef du dernier exemple.
Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Vous avez raison j'avais écris trop vite et j'avais même expliqué dans le
passé que ça serait plus facile de faire une attaque forcé en essayant toutes les clefs possibles quitte à prendre des siècles. a+ Raymond H.
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: crfckb$2tgs$1@biggoron.nerim.net...
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver
la
clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au
cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite
continue à K1 pour recommencer, et grâce à cela l'algèbre est possible
pour
trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses
propriétés algébriques (xor, oui, je sais, mais bon...) font que la
clé est (linéairement) dépendante du clair et du chiffré.
Disons que je ne suis pas tout à fait d'accord. Je dirais plutôt que si
chaque caractère de la clef dépend au moins de deux autres caractères de la
clef alors là c'est possible (dans notre exemple), mais si un seul caractère
ne dépend plus de deux autres caractères de la clef alors là se serait
impossible dans notre exemple.
Exemple: si k2 est dépendant de k3 pour M2 et est aussi dépendant de k1
pour M1 alors là on peut trouver la clef puisque tous les caractères sont en
relation avec un caractère qui le précèdent et un autre caractères qui le
suit (comme si on attacherait le début avec la fin et ainsi créer une roue
qui tourne et dont tous les engrenages dépendent les uns des autres). Du
moins c'est ce que je pense pour notre exemple. Vous pourriez vérifier avec
l'exemple que je mets dans le message en question dans ce fil et où je vais
mettre le calcul algébrique qui trouve la clef du dernier exemple.
Je vais vérifier,
via l'algèbre, si c'est aussi possible pour trouver le clair à partir de
l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et
les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Vous avez raison j'avais écris trop vite et j'avais même expliqué dans le
passé que ça serait plus facile de faire une attaque forcé en essayant
toutes les clefs possibles quitte à prendre des siècles.
a+
Raymond H.
"Christophe HENRY" a écrit dans le message de news: crfckb$2tgs$
En fin de compte j'ai testé avec l'algèbre et j'ai réussi à trouver la clef à partir du chiffré et du clair. Si je ne me trompe, cela est dû au cycle qui se connecte: je veux dire qu'au dernier caractère K3 la suite continue à K1 pour recommencer, et grâce à cela l'algèbre est possible pour trouver la clef dans notre petit exemple 'Simple algo'.
Ce n'est pas compliqué : dès que tu peux inverser ton calcul, ses propriétés algébriques (xor, oui, je sais, mais bon...) font que la clé est (linéairement) dépendante du clair et du chiffré.
Disons que je ne suis pas tout à fait d'accord. Je dirais plutôt que si chaque caractère de la clef dépend au moins de deux autres caractères de la clef alors là c'est possible (dans notre exemple), mais si un seul caractère ne dépend plus de deux autres caractères de la clef alors là se serait impossible dans notre exemple.
Exemple: si k2 est dépendant de k3 pour M2 et est aussi dépendant de k1 pour M1 alors là on peut trouver la clef puisque tous les caractères sont en relation avec un caractère qui le précèdent et un autre caractères qui le suit (comme si on attacherait le début avec la fin et ainsi créer une roue qui tourne et dont tous les engrenages dépendent les uns des autres). Du moins c'est ce que je pense pour notre exemple. Vous pourriez vérifier avec l'exemple que je mets dans le message en question dans ce fil et où je vais mettre le calcul algébrique qui trouve la clef du dernier exemple.
Je vais vérifier, via l'algèbre, si c'est aussi possible pour trouver le clair à partir de l'algo et du chiffré uniquement.
Inutile d'aller plus loin : c'est impossible vu les formules actuelles et les sacro-saintes conditions d'utilisations (aléa, distribution, etc.).
Vous avez raison j'avais écris trop vite et j'avais même expliqué dans le
passé que ça serait plus facile de faire une attaque forcé en essayant toutes les clefs possibles quitte à prendre des siècles. a+ Raymond H.
