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 n'ai pas compris comment tu fais pour decrypter
par contre si tu veux faire du cryptage avec les additions tu prends algo de compression publie plus bas et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m + cuissine bminNet bmin(N-1)
par contre moi je ne garantis pas la securite
bonne fete
r.h.
J'attends vos suggestions.
je n'ai pas compris comment tu fais pour
decrypter
par contre si tu veux faire du cryptage
avec les additions
tu prends algo de compression publie plus bas
et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m
+ cuissine bminNet bmin(N-1)
je n'ai pas compris comment tu fais pour decrypter
par contre si tu veux faire du cryptage avec les additions tu prends algo de compression publie plus bas et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m + cuissine bminNet bmin(N-1)
par contre moi je ne garantis pas la securite
bonne fete
r.h.
Raymond H.
"remy" a écrit dans le message de news: 41ca8681$0$30827$
J'attends vos suggestions.
je n'ai pas compris comment tu fais pour decrypter
Bonjour,
pour décrypter on fait le calcul inverse en partant du premier caractère de la clef. Le texte crypté à décrypter (en ascii) = 152 155 151 La clef est 12 (donc 49-50 en ascii). Donc: 49-50 152-155- 151 On fait donc: 151 - 49 - 49 S 155 - 50 - 53 = 52 152 - 49 - 52 = 51 En inversant, on arrive donc à 51-52-53 en ascii et on transforme en caractères pour arriver à 345 comme texte décrypté. C'est pour cela que je disais dans mes messages précédents que ce n'est pas les longs calculs compliqués qui font qu'un algorithme est meilleur mais la logique qui doit être le plus simple possible. Et de cette façon, les multiplications, divisions, soustractions, etc. dans un cryptage ne donnent pas grand chose de plus à mon avis sinon de prendre plus de temps au microprocesseur en bout de ligne, et les chiffres ne sont pas nécessairement plus difficiles à reconstituer par inversion. Bien entendu cela fait exception dépendant de la logique utilisée comme par exemple avec le modulo ou le Xor dans le cryptage.
Je ne conseille pas nécessairement faire un logiciel de cryptage juste avec cette façon de calculer car on peut ajouter plus de cassures comme le Xor etc..
Je ne prétend pas être meilleur dans la cryptologie que la plupart d'entre vous sur ce forum, mais disons que j'ai une approche un peu différente que certains ont. Je crois à la simplicité et c'est pour cela que j'ESSAIS de construire autour d'une logique simple qui peut tenir la route. C'est ce que je m'applique à faire pour la version 3 (qui demeure compatible avec les précédentes) dont je suis encore en train de ruminer l'algo.
par contre si tu veux faire du cryptage avec les additions tu prends algo de compression publie plus bas et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m + cuissine bminNet bmin(N-1)
Ici, je ne comprends pas ce que vous dites. C'est pourquoi avec un exemple ça serait plus clair pour moi.
par contre moi je ne garantis pas la securite
bonne fete
Vous pareillement :) Raymond H.
r.h.
"remy" <remy@fctpas.fr> a écrit dans le message de news:
41ca8681$0$30827$8fcfb975@news.wanadoo.fr...
J'attends vos suggestions.
je n'ai pas compris comment tu fais pour
decrypter
Bonjour,
pour décrypter on fait le calcul inverse en partant du premier caractère
de la clef.
Le texte crypté à décrypter (en ascii) = 152 155 151
La clef est 12 (donc 49-50 en ascii).
Donc:
49-50
152-155- 151
On fait donc:
151 - 49 - 49 S
155 - 50 - 53 = 52
152 - 49 - 52 = 51
En inversant, on arrive donc à 51-52-53 en ascii et on transforme en
caractères pour arriver à 345 comme texte décrypté. C'est pour cela que je
disais dans mes messages précédents que ce n'est pas les longs calculs
compliqués qui font qu'un algorithme est meilleur mais la logique qui doit
être le plus simple possible. Et de cette façon, les multiplications,
divisions, soustractions, etc. dans un cryptage ne donnent pas grand chose
de plus à mon avis sinon de prendre plus de temps au microprocesseur en bout
de ligne, et les chiffres ne sont pas nécessairement plus difficiles à
reconstituer par inversion. Bien entendu cela fait exception dépendant de
la logique utilisée comme par exemple avec le modulo ou le Xor dans le
cryptage.
Je ne conseille pas nécessairement faire un logiciel de cryptage juste
avec cette façon de calculer car on peut ajouter plus de cassures comme le
Xor etc..
Je ne prétend pas être meilleur dans la cryptologie que la plupart
d'entre vous sur ce forum, mais disons que j'ai une approche un peu
différente que certains ont. Je crois à la simplicité et c'est pour cela
que j'ESSAIS de construire autour d'une logique simple qui peut tenir la
route. C'est ce que je m'applique à faire pour la version 3 (qui demeure
compatible avec les précédentes) dont je suis encore en train de ruminer
l'algo.
par contre si tu veux faire du cryptage
avec les additions
tu prends algo de compression publie plus bas
et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m
+ cuissine bminNet bmin(N-1)
Ici, je ne comprends pas ce que vous dites. C'est pourquoi avec un exemple
ça serait plus clair pour moi.
"remy" a écrit dans le message de news: 41ca8681$0$30827$
J'attends vos suggestions.
je n'ai pas compris comment tu fais pour decrypter
Bonjour,
pour décrypter on fait le calcul inverse en partant du premier caractère de la clef. Le texte crypté à décrypter (en ascii) = 152 155 151 La clef est 12 (donc 49-50 en ascii). Donc: 49-50 152-155- 151 On fait donc: 151 - 49 - 49 S 155 - 50 - 53 = 52 152 - 49 - 52 = 51 En inversant, on arrive donc à 51-52-53 en ascii et on transforme en caractères pour arriver à 345 comme texte décrypté. C'est pour cela que je disais dans mes messages précédents que ce n'est pas les longs calculs compliqués qui font qu'un algorithme est meilleur mais la logique qui doit être le plus simple possible. Et de cette façon, les multiplications, divisions, soustractions, etc. dans un cryptage ne donnent pas grand chose de plus à mon avis sinon de prendre plus de temps au microprocesseur en bout de ligne, et les chiffres ne sont pas nécessairement plus difficiles à reconstituer par inversion. Bien entendu cela fait exception dépendant de la logique utilisée comme par exemple avec le modulo ou le Xor dans le cryptage.
Je ne conseille pas nécessairement faire un logiciel de cryptage juste avec cette façon de calculer car on peut ajouter plus de cassures comme le Xor etc..
Je ne prétend pas être meilleur dans la cryptologie que la plupart d'entre vous sur ce forum, mais disons que j'ai une approche un peu différente que certains ont. Je crois à la simplicité et c'est pour cela que j'ESSAIS de construire autour d'une logique simple qui peut tenir la route. C'est ce que je m'applique à faire pour la version 3 (qui demeure compatible avec les précédentes) dont je suis encore en train de ruminer l'algo.
par contre si tu veux faire du cryptage avec les additions tu prends algo de compression publie plus bas et ta cle sera la premiere bmin, et le nb d'octets concatenes ,nb m + cuissine bminNet bmin(N-1)
Ici, je ne comprends pas ce que vous dites. C'est pourquoi avec un exemple ça serait plus clair pour moi.
par contre moi je ne garantis pas la securite
bonne fete
Vous pareillement :) Raymond H.
r.h.
remy
re cela ne peut pas etre tres solide parce que la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la portee de qui tu veux et en plus tu peux attaquer ton fichier a partir de clair /chiffre
meme topo pour mon truc
remy
re
cela ne peut pas etre tres solide parce que
la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la
portee de qui tu veux
et en plus tu peux attaquer ton fichier
a partir de clair /chiffre
re cela ne peut pas etre tres solide parce que la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la portee de qui tu veux et en plus tu peux attaquer ton fichier a partir de clair /chiffre
meme topo pour mon truc
remy
Raymond H.
"remy" a écrit dans le message de news: 41caa27f$0$10411$
re cela ne peut pas etre tres solide parce que la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la portee de qui tu veux
Dans notre exemple, dans ce cas il faudrait que ce soit la même clef qu'on utilise pour les deux fichiers. N'est-ce pas? Dans ce cas, un à trois caractères choisis aléatoirement et placés avant l'en-tête elle-même réglerait le cas.
r.h.
et en plus tu peux attaquer ton fichier a partir de clair /chiffre
meme topo pour mon truc
remy
"remy" <remy@fctpas.fr> a écrit dans le message de news:
41caa27f$0$10411$8fcfb975@news.wanadoo.fr...
re
cela ne peut pas etre tres solide parce que
la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la
portee de qui tu veux
Dans notre exemple, dans ce cas il faudrait que ce soit la même clef qu'on
utilise pour les deux fichiers. N'est-ce pas? Dans ce cas, un à trois
caractères choisis aléatoirement et placés avant l'en-tête elle-même
réglerait le cas.
r.h.
et en plus tu peux attaquer ton fichier
a partir de clair /chiffre
"remy" a écrit dans le message de news: 41caa27f$0$10411$
re cela ne peut pas etre tres solide parce que la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la portee de qui tu veux
Dans notre exemple, dans ce cas il faudrait que ce soit la même clef qu'on utilise pour les deux fichiers. N'est-ce pas? Dans ce cas, un à trois caractères choisis aléatoirement et placés avant l'en-tête elle-même réglerait le cas.
r.h.
et en plus tu peux attaquer ton fichier a partir de clair /chiffre
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas tout saisi, pour déchiffrer ton texte... il te faut le texte en clair ?! Donc, le chiffré fera déjà le double du clair ? Et puis, si le clair est stocké avec le chiffré, heu... :-)
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas tout
saisi, pour déchiffrer ton texte... il te faut le texte en clair ?! Donc, le
chiffré fera déjà le double du clair ? Et puis, si le clair est stocké avec
le chiffré, heu... :-)
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas tout saisi, pour déchiffrer ton texte... il te faut le texte en clair ?! Donc, le chiffré fera déjà le double du clair ? Et puis, si le clair est stocké avec le chiffré, heu... :-)
-- AMcD®
http://arnold.mcdonald.free.fr/
remy
"Raymond H." a écrit dans le message de news: 5Fxyd.28382$
"remy" a écrit dans le message de news: 41caa27f$0$10411$
re cela ne peut pas etre tres solide parce que la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la portee de qui tu veux
Dans notre exemple, dans ce cas il faudrait que ce soit la même clef qu'on utilise pour les deux fichiers. N'est-ce pas? non
Ce que je veux dire est que pour que l'en-tête soit connu de la façon que vous dites, il faudrait qu'une autre personne ait la même clef que la première personne. Mais, si elle a la même clef c'est qu'elle peut de toute façon décrypter avec cette clef. C'est peu probable que deux personnes qui aient la même clef (tout en le sachant) et qu'en plus qu'il vienne à l'idée de comparer son chiffré avec celui d'un autre qui par hasard a la même clef.
J'ai oublié de dire que, dans notre exemple, si on ajoute un caractère choisi aléatoirement, il faudrait qu'à partir de sa valeur une autre valeur incrémentale soit additionné non seulement à la valeur de ce premier caractère mais à tous les caractères qui suivent et de façon incrémentale. Ainsi, deux textes en clair ne donneraient pas le même chiffré.
a+ r.h.
mais bon j'ai un putain de mal au crane alors .... le plus simple pour moi c'est de partir en vacances ou de faire une grosse pause
by remy
"remy" <remy@fctpas.fr> a écrit dans le message de news:
41cac32b$0$32154$8fcfb975@news.wanadoo.fr...
"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de news:
5Fxyd.28382$GK5.1443936@news20.bellglobal.com...
"remy" <remy@fctpas.fr> a écrit dans le message de news:
41caa27f$0$10411$8fcfb975@news.wanadoo.fr...
re
cela ne peut pas etre tres solide parce que
la resistance de l'algo est lie a la longueur de la cle de depart
un fichier avec un en-tete standard et tu mets tout a la
portee de qui tu veux
Dans notre exemple, dans ce cas il faudrait que ce soit la même clef
qu'on
utilise pour les deux fichiers. N'est-ce pas?
non
Ce que je veux dire est que pour que l'en-tête soit connu de la façon
que vous dites, il faudrait qu'une autre personne ait la même clef que la
première personne. Mais, si elle a la même clef c'est qu'elle peut de toute
façon décrypter avec cette clef. C'est peu probable que deux personnes qui
aient la même clef (tout en le sachant) et qu'en plus qu'il vienne à l'idée
de comparer son chiffré avec celui d'un autre qui par hasard a la même clef.
J'ai oublié de dire que, dans notre exemple, si on ajoute un caractère
choisi aléatoirement, il faudrait qu'à partir de sa valeur une autre valeur
incrémentale soit additionné non seulement à la valeur de ce premier
caractère mais à tous les caractères qui suivent et de façon incrémentale.
Ainsi, deux textes en clair ne donneraient pas le même chiffré.
a+
r.h.
mais bon j'ai un putain de mal au crane
alors ....
le plus simple pour moi c'est de partir en vacances
ou de faire une grosse pause
Ce que je veux dire est que pour que l'en-tête soit connu de la façon que vous dites, il faudrait qu'une autre personne ait la même clef que la première personne. Mais, si elle a la même clef c'est qu'elle peut de toute façon décrypter avec cette clef. C'est peu probable que deux personnes qui aient la même clef (tout en le sachant) et qu'en plus qu'il vienne à l'idée de comparer son chiffré avec celui d'un autre qui par hasard a la même clef.
J'ai oublié de dire que, dans notre exemple, si on ajoute un caractère choisi aléatoirement, il faudrait qu'à partir de sa valeur une autre valeur incrémentale soit additionné non seulement à la valeur de ce premier caractère mais à tous les caractères qui suivent et de façon incrémentale. Ainsi, deux textes en clair ne donneraient pas le même chiffré.
a+ r.h.
mais bon j'ai un putain de mal au crane alors .... le plus simple pour moi c'est de partir en vacances ou de faire une grosse pause
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas tout saisi, pour déchiffrer ton texte... il te faut le texte en clair ? ! Donc, le chiffré fera déjà le double du clair ? Et puis, si le clair est stocké avec le chiffré, heu... :-)
Bonjour :-)
Pour déchiffrer un caractère chiffré il faudra auparavant avoir déchiffré le caractère qui vient juste après (à sa droite). On ne peut donc pas premièrement déchiffrer c(1) puisque m(2) n'est pas encore connu. Il faut donc commencer par la fin: on déchiffre c(3) pour trouver m(3) et ensuite on se sert de m3 (et du caractère correspondant de la clef) pour déchiffrer c(2) et ainsi de suite jusqu'au début. Chaque caractère dépend de son caractère voisin et du caractère correspondant de la clef.
Dans l'exemple d'une clef (k1, k2, k3), on commence donc par
m(3) = c(3) - k(3) - k(1)
ici 'k(1)' remplace donc 'm(3+1)' puique celui-ci n'existe pas au début du décrypate.
puis on continu avec
m(i) = c(i) - k(i) - m(i+1)
Si la taille de la chaîne est différente de celle de la clef, il faut débuter le décryptage par 'k(1)' et le caractère de la clef 'k(?)' qui a été utilisé le dernier pour crypter le dernier caractère de la chaîne. Pour cela on pourrait faire " 'longueur de la chaîne' Modulo 'longueur de la clef' " pour connaître le dernier caractère de la clef qui a été utilisé pour le cryptage et faire, avec la clef, une boucle inverse à partir de ce caractère de la clef qui a été utilisé le dernier pour le cryptage.
Je ne sais pas si mon explication est assez claire!
Mais pour la version 3 d'AllCrypter je prends en compte non seulement m(i+1) mais aussi m(i-1). Or, le c(i-1) est calculé à partir d'un caractère de la clef avec XOR puis avec un modulo qui dépend d'un nombre variable aussi, et quelques autres variables. Je fais mes calculs et mes tests en utilisant des caractères NUL (ascii zéro) pour la clef et aussi pour les données à chiffrer, cela afin de m'assurer que le chiffré n'ait pas de répétitions dans les caractères.
Cependant la clef génère un code d'indentification irréversible qui peut (ou non) être inclue avec les données à chiffrer (dans ce cas il pourrait même être intégré au début des données en clair), mais au lieu que ce soit ce code qui soit utilisé pour décrypter (entre la clef et les données à chiffrer) c'est une autre chaîne générer à partir de la clef via un certain calcul qui prend en compte différentes valeurs de caractères de la clef inter reliées entre elles et d'autres valeurs.
Je m'assure donc que cette chaîne générée fasse en sorte que le chiffré ait des données différentes et cela même si j'utiliserais une clef n'ayant que des caractères NUL (ascii zéro) et des données à chiffrer ayant aussi seulement des caractères NUL (ascii zéro). Disons que je suis encore en train de travailler cela. Et pour ajouter à la confusion, je débute donc chaque paquet (à crypter) par un caractère choisi au hasard, et au décryptage celui-ci est retiré puisqu'il n'a servi qu'à faire changer la valeur de départ qui a été généré par la clef et la chaîne généré par la clef (en rapport avec le 1er caractère véritable du texte clair. Un peu difficile à expliquer mais plus tard je veux étaler cela en détail (étape par étape) sur une page Web le temps venu.
a+
Raymond H.
-- AMcD®
http://arnold.mcdonald.free.fr/
"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
41cabf7c$0$2592$626a14ce@news.free.fr...
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas
tout saisi, pour déchiffrer ton texte... il te faut le texte en clair ?
! Donc, le chiffré fera déjà le double du clair ? Et puis, si le clair est
stocké avec le chiffré, heu... :-)
Bonjour :-)
Pour déchiffrer un caractère chiffré il faudra auparavant avoir
déchiffré le caractère qui vient juste après (à sa droite). On ne peut donc
pas premièrement déchiffrer c(1) puisque m(2) n'est pas encore connu. Il
faut donc commencer par la fin: on déchiffre c(3) pour trouver m(3) et
ensuite on se sert de m3 (et du caractère correspondant de la clef) pour
déchiffrer c(2) et ainsi de suite jusqu'au début. Chaque caractère dépend
de son caractère voisin et du caractère correspondant de la clef.
Dans l'exemple d'une clef (k1, k2, k3), on commence donc par
m(3) = c(3) - k(3) - k(1)
ici 'k(1)' remplace donc 'm(3+1)' puique celui-ci n'existe pas au début du
décrypate.
puis on continu avec
m(i) = c(i) - k(i) - m(i+1)
Si la taille de la chaîne est différente de celle de la clef, il faut
débuter le décryptage par 'k(1)' et le caractère de la clef 'k(?)' qui a
été utilisé le dernier pour crypter le dernier caractère de la chaîne. Pour
cela on pourrait faire " 'longueur de la chaîne' Modulo 'longueur de la
clef' " pour connaître le dernier caractère de la clef qui a été utilisé
pour le cryptage et faire, avec la clef, une boucle inverse à partir de ce
caractère de la clef qui a été utilisé le dernier pour le cryptage.
Je ne sais pas si mon explication est assez claire!
Mais pour la version 3 d'AllCrypter je prends en compte non seulement
m(i+1) mais aussi m(i-1). Or, le c(i-1) est calculé à partir d'un caractère
de la clef avec XOR puis avec un modulo qui dépend d'un nombre variable
aussi, et quelques autres variables. Je fais mes calculs et mes tests en
utilisant des caractères NUL (ascii zéro) pour la clef et aussi pour les
données à chiffrer, cela afin de m'assurer que le chiffré n'ait pas de
répétitions dans les caractères.
Cependant la clef génère un code d'indentification irréversible qui peut
(ou non) être inclue avec les données à chiffrer (dans ce cas il pourrait
même être intégré au début des données en clair), mais au lieu que ce soit
ce code qui soit utilisé pour décrypter (entre la clef et les données à
chiffrer) c'est une autre chaîne générer à partir de la clef via un certain
calcul qui prend en compte différentes valeurs de caractères de la clef
inter reliées entre elles et d'autres valeurs.
Je m'assure donc que cette chaîne générée fasse en sorte que le chiffré
ait des données différentes et cela même si j'utiliserais une clef n'ayant
que des caractères NUL (ascii zéro) et des données à chiffrer ayant aussi
seulement des caractères NUL (ascii zéro). Disons que je suis encore en
train de travailler cela. Et pour ajouter à la confusion, je débute donc
chaque paquet (à crypter) par un caractère choisi au hasard, et au
décryptage celui-ci est retiré puisqu'il n'a servi qu'à faire changer la
valeur de départ qui a été généré par la clef et la chaîne généré par la
clef (en rapport avec le 1er caractère véritable du texte clair. Un peu
difficile à expliquer mais plus tard je veux étaler cela en détail (étape
par étape) sur une page Web le temps venu.
Excepté les longueurs égales à celle de la clé on a :
c(i) = k(i] + m(i) + m(i+1)
Là où je m'interroge, c'est que pour inverser, tu vas donc faire :
m1 = c1 - k1 - m2 = 51
Bref, pour toutes les longeurs inférieures à la longueur de clé moins 1 :
m(i) = c(i) - k(i) - m(i+1)
Donc, l'inversion de m(i) dépendant de m(i+1), à moins que je n'ai pas tout saisi, pour déchiffrer ton texte... il te faut le texte en clair ? ! Donc, le chiffré fera déjà le double du clair ? Et puis, si le clair est stocké avec le chiffré, heu... :-)
Bonjour :-)
Pour déchiffrer un caractère chiffré il faudra auparavant avoir déchiffré le caractère qui vient juste après (à sa droite). On ne peut donc pas premièrement déchiffrer c(1) puisque m(2) n'est pas encore connu. Il faut donc commencer par la fin: on déchiffre c(3) pour trouver m(3) et ensuite on se sert de m3 (et du caractère correspondant de la clef) pour déchiffrer c(2) et ainsi de suite jusqu'au début. Chaque caractère dépend de son caractère voisin et du caractère correspondant de la clef.
Dans l'exemple d'une clef (k1, k2, k3), on commence donc par
m(3) = c(3) - k(3) - k(1)
ici 'k(1)' remplace donc 'm(3+1)' puique celui-ci n'existe pas au début du décrypate.
puis on continu avec
m(i) = c(i) - k(i) - m(i+1)
Si la taille de la chaîne est différente de celle de la clef, il faut débuter le décryptage par 'k(1)' et le caractère de la clef 'k(?)' qui a été utilisé le dernier pour crypter le dernier caractère de la chaîne. Pour cela on pourrait faire " 'longueur de la chaîne' Modulo 'longueur de la clef' " pour connaître le dernier caractère de la clef qui a été utilisé pour le cryptage et faire, avec la clef, une boucle inverse à partir de ce caractère de la clef qui a été utilisé le dernier pour le cryptage.
Je ne sais pas si mon explication est assez claire!
Mais pour la version 3 d'AllCrypter je prends en compte non seulement m(i+1) mais aussi m(i-1). Or, le c(i-1) est calculé à partir d'un caractère de la clef avec XOR puis avec un modulo qui dépend d'un nombre variable aussi, et quelques autres variables. Je fais mes calculs et mes tests en utilisant des caractères NUL (ascii zéro) pour la clef et aussi pour les données à chiffrer, cela afin de m'assurer que le chiffré n'ait pas de répétitions dans les caractères.
Cependant la clef génère un code d'indentification irréversible qui peut (ou non) être inclue avec les données à chiffrer (dans ce cas il pourrait même être intégré au début des données en clair), mais au lieu que ce soit ce code qui soit utilisé pour décrypter (entre la clef et les données à chiffrer) c'est une autre chaîne générer à partir de la clef via un certain calcul qui prend en compte différentes valeurs de caractères de la clef inter reliées entre elles et d'autres valeurs.
Je m'assure donc que cette chaîne générée fasse en sorte que le chiffré ait des données différentes et cela même si j'utiliserais une clef n'ayant que des caractères NUL (ascii zéro) et des données à chiffrer ayant aussi seulement des caractères NUL (ascii zéro). Disons que je suis encore en train de travailler cela. Et pour ajouter à la confusion, je débute donc chaque paquet (à crypter) par un caractère choisi au hasard, et au décryptage celui-ci est retiré puisqu'il n'a servi qu'à faire changer la valeur de départ qui a été généré par la clef et la chaîne généré par la clef (en rapport avec le 1er caractère véritable du texte clair. Un peu difficile à expliquer mais plus tard je veux étaler cela en détail (étape par étape) sur une page Web le temps venu.
a+
Raymond H.
-- AMcD®
http://arnold.mcdonald.free.fr/
Raymond H.
"Manu" a écrit dans le message de news: cqgggd$9aa$
était bien correct car dans l'exemple il n'y a pas de 'k3' dans la clef à deux caractères, et l'un des deux 'k1' remplace 'm4' [m(3+1)] qui n'existe pas puisqu'on est au dernier caractère. Et l'autre 'k1' est la suite de 'k2' :-)
a+ Raymond H.
"Manu" <el@netcourrier.com> a écrit dans le message de news:
cqgggd$9aa$1@reader1.imaginet.fr...
"AMcD®" <arnold.mcdonald@free.fr> wrote in message
news:41cabf7c$0$2592$626a14ce@news.free.fr...
était bien correct car dans l'exemple il n'y a pas de 'k3' dans la clef à
deux caractères, et l'un des deux 'k1' remplace 'm4' [m(3+1)] qui n'existe
pas puisqu'on est au dernier caractère. Et l'autre 'k1' est la suite de
'k2' :-)
était bien correct car dans l'exemple il n'y a pas de 'k3' dans la clef à deux caractères, et l'un des deux 'k1' remplace 'm4' [m(3+1)] qui n'existe pas puisqu'on est au dernier caractère. Et l'autre 'k1' est la suite de 'k2' :-)
