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
Je me doutais bien que ça serait possible. Je vais essayer de trouver la solution du problème ci-avant par un exemple en algèbre pour l'ajouter dans mon prochain message avec peut-être une nouvelle tentative 'POUR' empêcher de trouver la clef. Si quelqu'un a une petite idée via un exemple...
Cordialement
r.h.
Bonjour,
Voici le calcul algébrique pour trouver la clef dans cet exemple. Un peu long à la main :-) 51+523 52+535 53+k1=?
Donc, 249-1036 donc 249-1036 donc k16-k2 281-1056 donc 281-1056 donc k26-k3 206-(53+k1)=k3+k1 donc k3 6-(53+k1)-k1
Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette fois-ci la variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai pas encore été capable (faudrait vérifier si c'est possible autrement). À mon avis, si l'algèbre ne le peut pas alors Scilab non plus. Exemple:
41 105 71 63 =k 51 52 53 =m 249 281 250 =c
c1=k1+k2+m1+m2 c2=k2+k3+m2+m3 c3=k3+k4+m3+k4 (k4 remplace aussi m4)
Ici le nombre 63 serait ajouté aléatoirement par le logiciel spécialement pour le dernier caractère du clair à chiffrer/déchiffrer. Ce nombre 63 serait ajouté à la fin du clair pour être chiffré avec le clair. Lors du déchiffrement, le logiciel commencerait pas déchiffrer ce caractères via les deux 1re caractères de la clef puis l'insérerait à la fin de la clef pour débuter le déchiffrage normalement. C'est juste une idée comme ça.
Ici on suppose qu'on ne fait pas de boucle avec la clef et qu'elle serait en réalité une sous chaîne générée par la clef et qu'elle serait de la même longueur que le clair plus un caractère.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque à clair connu!
Raymond H.
"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de news:
3%pCd.11350$P%3.1011983@news20.bellglobal.com...
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: crcfme$1kjc$2@biggoron.nerim.net...
Je me doutais bien que ça serait possible. Je vais essayer de trouver la
solution du problème ci-avant par un exemple en algèbre pour l'ajouter
dans mon prochain message avec peut-être une nouvelle tentative 'POUR'
empêcher de trouver la clef. Si quelqu'un a une petite idée via un
exemple...
Cordialement
r.h.
Bonjour,
Voici le calcul algébrique pour trouver la clef dans cet exemple. Un
peu long à la main :-)
51+523
52+535
53+k1=?
Donc,
249-1036 donc 249-1036 donc k16-k2
281-1056 donc 281-1056 donc k26-k3
206-(53+k1)=k3+k1 donc k3 6-(53+k1)-k1
Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette fois-ci la
variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai pas
encore été capable (faudrait vérifier si c'est possible autrement). À mon
avis, si l'algèbre ne le peut pas alors Scilab non plus.
Exemple:
41 105 71 63 =k
51 52 53 =m
249 281 250 =c
c1=k1+k2+m1+m2
c2=k2+k3+m2+m3
c3=k3+k4+m3+k4 (k4 remplace aussi m4)
Ici le nombre 63 serait ajouté aléatoirement par le logiciel
spécialement pour le dernier caractère du clair à chiffrer/déchiffrer. Ce
nombre 63 serait ajouté à la fin du clair pour être chiffré avec le clair.
Lors du déchiffrement, le logiciel commencerait pas déchiffrer ce caractères
via les deux 1re caractères de la clef puis l'insérerait à la fin de la clef
pour débuter le déchiffrage normalement. C'est juste une idée comme ça.
Ici on suppose qu'on ne fait pas de boucle avec la clef et qu'elle
serait en réalité une sous chaîne générée par la clef et qu'elle serait de
la même longueur que le clair plus un caractère.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque à
clair connu!
Je me doutais bien que ça serait possible. Je vais essayer de trouver la solution du problème ci-avant par un exemple en algèbre pour l'ajouter dans mon prochain message avec peut-être une nouvelle tentative 'POUR' empêcher de trouver la clef. Si quelqu'un a une petite idée via un exemple...
Cordialement
r.h.
Bonjour,
Voici le calcul algébrique pour trouver la clef dans cet exemple. Un peu long à la main :-) 51+523 52+535 53+k1=?
Donc, 249-1036 donc 249-1036 donc k16-k2 281-1056 donc 281-1056 donc k26-k3 206-(53+k1)=k3+k1 donc k3 6-(53+k1)-k1
Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette fois-ci la variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai pas encore été capable (faudrait vérifier si c'est possible autrement). À mon avis, si l'algèbre ne le peut pas alors Scilab non plus. Exemple:
41 105 71 63 =k 51 52 53 =m 249 281 250 =c
c1=k1+k2+m1+m2 c2=k2+k3+m2+m3 c3=k3+k4+m3+k4 (k4 remplace aussi m4)
Ici le nombre 63 serait ajouté aléatoirement par le logiciel spécialement pour le dernier caractère du clair à chiffrer/déchiffrer. Ce nombre 63 serait ajouté à la fin du clair pour être chiffré avec le clair. Lors du déchiffrement, le logiciel commencerait pas déchiffrer ce caractères via les deux 1re caractères de la clef puis l'insérerait à la fin de la clef pour débuter le déchiffrage normalement. C'est juste une idée comme ça.
Ici on suppose qu'on ne fait pas de boucle avec la clef et qu'elle serait en réalité une sous chaîne générée par la clef et qu'elle serait de la même longueur que le clair plus un caractère.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque à clair connu!
Raymond H.
Christophe HENRY
... Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette fois-ci la variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai pas encore été capable (faudrait vérifier si c'est possible autrement). À mon avis, si l'algèbre ne le peut pas alors Scilab non plus.
Raté ! Ce n'est pas scilab qui le fait, c'est juste des mathématiques.
... Ici le nombre 63 serait ajouté aléatoirement par le logiciel spécialement pour le dernier caractère du clair à chiffrer/déchiffrer. Ce nombre 63 serait ajouté à la fin du clair pour être chiffré avec le clair. Lors du déchiffrement, le logiciel commencerait pas déchiffrer ce caractères via les deux 1re caractères de la clef puis l'insérerait à la fin de la clef pour débuter le déchiffrage normalement. C'est juste une idée comme ça.
Effectivement, la clé est dorénavant non déterminable de manière unique. La matrice addossée à la clé est rectangulaire et de ce fait non-inversible.
le k4 supplémentaire provoque une relation entre deux (désolé) espaces vectoriels de dimensions différentes. Cette application est non-injective, ce qui entraîne une bonne et une mauvaise nouvelle :
1/ il n'est pas possible de retrouver une clé unique à partir d'un clair et d'un chiffré.
2/ il est possible de trouver plusieurs clés à partir d'un clair et d'un chiffré. Plusieurs clés qui font ainsi le même chiffrement et déchiffrement.
L'attaque à clair et chiffré connu évoqué par "Mister Jack" est toujours faisable car la connaissance de la clé n'est pas nécessaire.
Donc toutes les attaques restent possibles, et il n'y en a même d'autres maintenant.
==Cryptanalyse d'un chiffré à partir d'un autre clair/chiffré ==traités avec la même clé
Dans la théorie, le noyau de la matrice Mk (affublé du k4) n'est plus zéro mais une droite. De ce fait, on définit le vecteur [-2;2;-2;1] permettant de parcourir chaque faisceau sans sortir de la classe d'équivalence, et donc d'avoir une clé différente mais au chiffrement équivalent.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque à clair connu!
Tu es parti pour la deuxième.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
...
Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette
fois-ci la
variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai
pas encore été capable (faudrait vérifier si c'est possible
autrement). À mon avis, si l'algèbre ne le peut pas alors Scilab non
plus.
Raté ! Ce n'est pas scilab qui le fait, c'est juste des mathématiques.
...
Ici le nombre 63 serait ajouté aléatoirement par le logiciel
spécialement pour le dernier caractère du clair à
chiffrer/déchiffrer. Ce nombre 63 serait ajouté à la fin du clair
pour être chiffré avec le clair. Lors du déchiffrement, le logiciel
commencerait pas déchiffrer ce caractères via les deux 1re caractères
de la clef puis l'insérerait à la fin de la clef pour débuter le
déchiffrage normalement. C'est juste une idée comme ça.
Effectivement, la clé est dorénavant non déterminable de manière
unique. La matrice addossée à la clé est rectangulaire et de ce fait
non-inversible.
le k4 supplémentaire provoque une relation entre deux (désolé) espaces
vectoriels de dimensions différentes. Cette application est
non-injective, ce qui entraîne une bonne et une mauvaise nouvelle :
1/ il n'est pas possible de retrouver une clé unique à partir d'un clair
et d'un chiffré.
2/ il est possible de trouver plusieurs clés à partir d'un clair et d'un
chiffré. Plusieurs clés qui font ainsi le même chiffrement et
déchiffrement.
L'attaque à clair et chiffré connu évoqué par "Mister Jack" est
toujours faisable car la connaissance de la clé n'est pas
nécessaire.
Donc toutes les attaques restent possibles, et il n'y en a même
d'autres maintenant.
==Cryptanalyse d'un chiffré à partir d'un autre clair/chiffré
==traités avec la même clé
Dans la théorie, le noyau de la matrice Mk (affublé du k4) n'est plus
zéro mais une droite. De ce fait, on définit le vecteur [-2;2;-2;1]
permettant de parcourir chaque faisceau sans sortir de la classe
d'équivalence, et donc d'avoir une clé différente mais au chiffrement
équivalent.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque
à clair connu!
Tu es parti pour la deuxième.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
... Pour tenter d'empêcher de trouver la clef, j'ai ajouté cette fois-ci la variable k4. J'ai essayé par l'algèbre de trouver la clef et je n'ai pas encore été capable (faudrait vérifier si c'est possible autrement). À mon avis, si l'algèbre ne le peut pas alors Scilab non plus.
Raté ! Ce n'est pas scilab qui le fait, c'est juste des mathématiques.
... Ici le nombre 63 serait ajouté aléatoirement par le logiciel spécialement pour le dernier caractère du clair à chiffrer/déchiffrer. Ce nombre 63 serait ajouté à la fin du clair pour être chiffré avec le clair. Lors du déchiffrement, le logiciel commencerait pas déchiffrer ce caractères via les deux 1re caractères de la clef puis l'insérerait à la fin de la clef pour débuter le déchiffrage normalement. C'est juste une idée comme ça.
Effectivement, la clé est dorénavant non déterminable de manière unique. La matrice addossée à la clé est rectangulaire et de ce fait non-inversible.
le k4 supplémentaire provoque une relation entre deux (désolé) espaces vectoriels de dimensions différentes. Cette application est non-injective, ce qui entraîne une bonne et une mauvaise nouvelle :
1/ il n'est pas possible de retrouver une clé unique à partir d'un clair et d'un chiffré.
2/ il est possible de trouver plusieurs clés à partir d'un clair et d'un chiffré. Plusieurs clés qui font ainsi le même chiffrement et déchiffrement.
L'attaque à clair et chiffré connu évoqué par "Mister Jack" est toujours faisable car la connaissance de la clé n'est pas nécessaire.
Donc toutes les attaques restent possibles, et il n'y en a même d'autres maintenant.
==Cryptanalyse d'un chiffré à partir d'un autre clair/chiffré ==traités avec la même clé
Dans la théorie, le noyau de la matrice Mk (affublé du k4) n'est plus zéro mais une droite. De ce fait, on définit le vecteur [-2;2;-2;1] permettant de parcourir chaque faisceau sans sortir de la classe d'équivalence, et donc d'avoir une clé différente mais au chiffrement équivalent.
Voilà pour ma tentative d'empêcher de trouver la clef par une attaque à clair connu!
Tu es parti pour la deuxième.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
