"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctia8g$6td$1@biggoron.nerim.net...
> Le Sun, 30 Jan 2005 02:40:27 -0500, Raymond H. a écrit :
>
>> Bonjour,
>>
>> Aie-je bien raison de penser que dans ces deux exemples le xor
>> serait
>> moins difficiles à inverser (déchiffrer) que l'addition, même si le
>> nombre
>> de possibilités du xor dépasse celui de l'addition?
>
> Aucune difficulté dans chacune des deux possibilités.
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il
ait utilisé soit un xor ou une addition?
>Ce qui m'a ennuyé
> (sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux
de mélanger les deux: car sinon on n'aurait que 256 possibilités tandis
qu'avec des additions on rend plus difficile le déchiffrage via
l'utilisation de l'algo (en inversion ou autre). Cela, dans l'optique où on
connaît déjà l'algo, afin de rendre aussi difficile l'inversion qu'une
attaque à force brute. C'est du moins ce que je conçoit.
Si ( 20 + 23 ) xor 22 = 61 , et qu'on soupçonne que la valeur
intermédiaire est 22 en ayant déjà le chiffré 61, il sera plus difficile de
trouver 20 que de trouver uniquement 43 (ici pensons à une attaque à clair
connue). Je parle concernant le prolongement de la clef. Mais concernant
le chiffrage je pense qu'un simple xor serait suffisant surtout si tout
repose sur la force de calcul du prolongement de la clef de session.
J'ai pris quelques temps pour ruminer quelle serait la façon la plus
simple et la plus certaine de faire l'algo. J'en suis venu à la conclusion
que si le seul algo incassable est celui de Gilbert Vernam en 1917, alors
pourquoi ne pas m'en inspirer pour faire quelque chose d'aussi certain qui
lui ressemble et tout en restant autant que possible aussi simple.
Il faut que je m'assure des points suivants:
1 - générer une clef imprévisible de la même longueur que le clair (une
seule clef par chiffrage).
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier par
exemple).
3 - ne conserver que la partie finale de la clef de session qui doit servir
pour le déchiffrage; celle-ci et l'identificateur de la phrase de passe
(généré par la phrase de passe) doivent être chiffrés ensemble par la phrase
de passe afin de les ajouter au chiffré existant. L'algo chiffrant la
phrase de passe et la clef session finale doit être aussi sûr que celui qui
génère le prolongement de la clef de session (car les 1er caractères de la
clef de session est généré aléatoirement: clef de session initiale).
4 - si les 3 premiers points sont rencontrés, le chiffrage du clair par un
simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Donc, un simple xor serait suffisant pour le chiffrage du clair; mais la
partie de l'algo générant (prolongeant) la clef de session devrait être plus
compliquer afin de créer des murs de feu dans celui-ci (dans '(Var1 + Var2)
xor Var3=255' l'addition serait un mur interdisant l'inversion); donc,
demandant une partie algorithmique plus compliqué (donc, à plusieurs
niveaux).
J'ai fais quelques tests pour savoir le nombre de possibilités à partir
de quelques calculs différents:
32896 possibilités: (V1 + V2 + V3)=255
65536 possibilités: (((V1 xor V2)xor V3)=255
256 possibilités: (V1 + V2)=255
256 possibilités: ((V1 xor V2)=28
128 possibilités: (k1+k1)xor k2=164
32896 possibilités: (k1+k2)xor k3=164
14652 possibilités: ((k1+k2)xor 53)+k3=164
1517673 possibilités: ((k1+k2)xor m1)+k3=164
0 possibilité: ((128+128)xor m1)+128=255
1 possibilité: (((128+128)xor m1)+128) Mod 256=255
165 possibilités: ((V1 xor V2)+V1=164
1 possibilité: ((V1 + 53)xor V1=255
203 possibilités: ((V1 + 53)xor V2=164
1 possibilité: ((V1 xor 53)=255
6724352 possibilités: (k1+k2)xor(k3+k4)=164
625364 possibilités: ((k1+k2+m1+m2)xor k2)+k1=164
1 possibilité: Var1 xor 64=255
J'ai fait des tests en codes de programmation pour voir quel calcul
rallonge la plus longue clef de session à partir d'une clef de session
initiale de seulement 4 caractères. J'ai mis des caractères ascii zéro (0)
pour le clair, puisqu'avec des caractères zéro il est plus difficile de
générer des caractères variés dans le rallongement de la clef de session.
k est la clef de session initiale. m est le clair (des caractères ascii
zéro; caractères Nul).
(k1+m1) xor (k3+k4)=k5 donne comme résultat un caractère de plus à ajouter à
la fin de la clef de session. Donc k=k & k5 La clef de session est donc
prolongée en étant influencé par le clair m1.
Donc, produit une clef de 224 caractères différents à partir de
caractères initiales 2222 (en ascii= 50 50 50 50). Le clair comporte donc
au dessus de 224 caractères ascii zéro.
Ici, le même calcul produit moins de caractères différents à partir de
la clef 1234 que la clef 2222. Mais plus bas on voit que c'est le contraire
avec un calcul différent.
Voici le résultat à partir d'autres calculs:
k=2222
m=0000...
((k1+k2)xor m1)+k3=
Donne une clef à 224 caractères différents.
k=1234
m=0000...
((k1+k2)xor m1)+k3=
Donne une clef à 896 caractères différents.
------------------------------
k=2222
m=0000...
(k1+m1) xor (k2+k3)=
Donne une clef à 224 caractères différents.
k=1234
m=0000...
(k1+m1) xor (k2+k3)=
Donne une clef à 896 caractères différents.
------------------------------
k=2222
m=0000...
(k1+k2) xor (m1+k3)+k4=
Donne une clef à 160 caractères différents
k=1234
m=0000...
(k1+k2) xor (m1+k3)+k4=
Donne une clef à 640 caractères différents
------------------------------
k=2222
m=0000...
((k1+k2) xor (m1+k3)) xor k4=
Donne une clef à 320 caractères différents
k=1234
m=0000...
((k1+k2) xor (m1+k3)) xor k4=
Donne une clef à 320 caractères différents
------------------------------
k=2222
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 448 caractères différents
k=1234
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 896 caractères différents
------------------------------
Donc, le calcul ici qui produit le plus de caractères différents à
partir soit de la clef (à 4 caractères) 2222 ou 1234 est
(k1+k2) xor (m1+k3)=
C'est justement le calcul qui donne le plus grand nombre de possibilité
parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables
différentes:
6724352 possibilités: (k1+k2)xor(k3+k4)=164
Prenons ce même calcul et ajoutons des caractères à la clef. Voici
quelques résultats assez convainquant:
k=22222
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 896 caractères différents
k=12345
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 448 caractères différents
------------------------------
k=222222
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 1984 caractères différents
k=123456
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 3968 caractères différents
------------------------------
k=2222222
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 1920 caractères différents
------------------------------
k=1234567 (3975 pas pareil)
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 3840 caractères différents
------------------------------
k=12345678
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 16256 caractères différents
------------------------------
k=123456789
m=0000...
(k1+k2) xor (m1+k3)=
Donne une clef à 16256 caractères différents
------------------------------
Donc, avec une clef de seulement 9 caractères et un clair qui contient
plus de 16256 caractères ascii zéro (0), cela donne une clef de session
comportant 16256 caractères différents.
Dans cet exemple, la clef '123456789' peut donc chiffrer un clair
d'environ 16 Kilo octets, et cela avec une clef de session n'ayant aucun
cycle de caractères qui se répète. En plus le clair comportait uniquement
des caractères ascii zéro (0), c'est à dire, le caractère NUL qui devrait
être le plus facile à utiliser pour déchiffrer.
On pourrait donc supposer que si le clair comportait des caractères
différents du caractère ascii zéro, cela pourrait donner une clef à l'infini
qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible
puisque influencé par le clair qui n'est pas connu dans son ensemble.
Pour éviter un cycle qui se répète lorsqu'on a un clair de plusieurs Mo
de caractères ascii zéro (ou de plusieurs caractère ayant le même nombre
ascii, tel les pixels d'un bitmap), j'ai pensé ajouté une incrémentation
dans la partie de l'algo (générant le prolongement de la clef) qui sert de
mur de feu, donc le numéro indiquant l'ordre du caractère actuel 'm1' qui
est utilisé pour le prolongement de la clef:
(k1+k2+Rép1) xor (m1+k3)=
Donc, si on est rendu à la lecture du dixième caractère du clair, alors
'Rép1' vaudrait la valeur 10.
Je suis rendu à réfléchir si une autre variable ayant une valeur
imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur
représentée par 'Var?', une valeur prise dans les caractères de la phrase de
passe, dans la clef de session ou dans le clair lui-même :
(k1+k2+Rép1+Var?) xor (m1+k3)=
kf=(ascii:) 243-076-177-235-237-161-002 = clef de session finale à conserver pour être chiffrée
Voilà!
Raymond H.
Christophe HENRY
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou xor, même combat.
Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi difficile l'inversion qu'une attaque à force brute. C'est du moins ce que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
... Mais concernant le chiffrage je pense qu'un simple xor serait suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
... Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable ; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair; mais la partie de l'algo générant (prolongeant) la clef de session devrait être plus compliquer afin de créer des murs de feu dans celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur interdisant l'inversion); donc, demandant une partie algorithmique plus compliqué (donc, à plusieurs niveaux). J'ai fais quelques tests pour savoir le nombre de possibilités à partir de quelques calculs différents: ...
Par une démonstration canonique, j'ai montré qu'un problème te semblant de l'ordre de la taille de l'univers (force brute) se réduisait, en fait, à une résolution (force "tranquille") dont la taille n'est pas mesurable tellement elle est petite.
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
... Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de sécurité au procédé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il
ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou
xor, même combat.
Ce qui m'a ennuyé
(sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux
de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela
introduit des redondances ouvrant la possibilité d'attaques à chiffré
seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi
difficile l'inversion qu'une attaque à force brute. C'est du moins ce
que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
...
Mais concernant le chiffrage je pense qu'un simple xor serait
suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
...
Il faut que je m'assure des points suivants:
1 - générer une clef imprévisible de la même longueur que le clair
(une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel
pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier
par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le
fait du hasard alors ce sera effectivement inattaquable ; le défaut est
qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée
l'est à partir du clair et présentera donc des redondances avec le
chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit
servir pour le déchiffrage; celle-ci et l'identificateur de la phrase
...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor
muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec
l'attaque à clair connue qui n'a besoin que d'un nombre restreint
d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait
suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et
bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair;
mais la partie de l'algo générant (prolongeant) la clef de session
devrait être plus compliquer afin de créer des murs de feu dans
celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur
interdisant l'inversion); donc, demandant une partie algorithmique plus
compliqué (donc, à plusieurs niveaux).
J'ai fais quelques tests pour savoir le nombre de possibilités à
partir
de quelques calculs différents:
...
Par une démonstration canonique, j'ai montré qu'un problème te semblant
de l'ordre de la taille de l'univers (force brute) se réduisait, en fait,
à une résolution (force "tranquille") dont la taille n'est pas mesurable
tellement elle est petite.
...
Donc, le calcul ici qui produit le plus de caractères différents
à
partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor
(m1+k3)
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de
possibilité
parmi les test que j'ai mentionnés au début (plus haut ici) à 4
variables différentes:
6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de
chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent
drastiquement l'espace des clés.
...
On pourrait donc supposer que si le clair comportait des caractères
différents du caractère ascii zéro, cela pourrait donner une clef à
l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère
prévisible puisque influencé par le clair qui n'est pas connu dans son
ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas
l'expliquer.
...
Je suis rendu à réfléchir si une autre variable ayant une valeur
imprévisible changeante devrait être ajoutée dans ce mur, disons une
valeur représentée par 'Var?', une valeur prise dans les caractères
de la phrase de passe, dans la clef de session ou dans le clair
lui-même : (k1+k2+Rép1+Var?) xor (m1+k3)
C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça
devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de
sécurité au procédé.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou xor, même combat.
Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi difficile l'inversion qu'une attaque à force brute. C'est du moins ce que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
... Mais concernant le chiffrage je pense qu'un simple xor serait suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
... Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable ; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair; mais la partie de l'algo générant (prolongeant) la clef de session devrait être plus compliquer afin de créer des murs de feu dans celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur interdisant l'inversion); donc, demandant une partie algorithmique plus compliqué (donc, à plusieurs niveaux). J'ai fais quelques tests pour savoir le nombre de possibilités à partir de quelques calculs différents: ...
Par une démonstration canonique, j'ai montré qu'un problème te semblant de l'ordre de la taille de l'univers (force brute) se réduisait, en fait, à une résolution (force "tranquille") dont la taille n'est pas mesurable tellement elle est petite.
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
... Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de sécurité au procédé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
bestcalinou
Moi je dirais qu'une chose, c'est que les crackeurs, ils s'embarrasent pas de trouver la clef de session mais ils remplacent la condition d'acceptation par "toujours vraie" directement dans le langage machine. D'où "SI code_session ok ALORS poursuite_execution, ...etc SINON fin_session" devient "SI vraie ALORS poursuite_execution, ...etc" Bon courage quand même.
"Christophe HENRY" a écrit dans le message de news: ctqbdu$j1t$
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou xor, même combat.
Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi difficile l'inversion qu'une attaque à force brute. C'est du moins ce que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
... Mais concernant le chiffrage je pense qu'un simple xor serait suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
... Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable ; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair; mais la partie de l'algo générant (prolongeant) la clef de session devrait être plus compliquer afin de créer des murs de feu dans celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur interdisant l'inversion); donc, demandant une partie algorithmique plus compliqué (donc, à plusieurs niveaux). J'ai fais quelques tests pour savoir le nombre de possibilités à partir de quelques calculs différents: ...
Par une démonstration canonique, j'ai montré qu'un problème te semblant de l'ordre de la taille de l'univers (force brute) se réduisait, en fait, à une résolution (force "tranquille") dont la taille n'est pas mesurable tellement elle est petite.
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) > La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
... Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) > C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de sécurité au procédé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Moi je dirais qu'une chose, c'est que les crackeurs, ils s'embarrasent pas
de trouver la clef de session mais ils remplacent la condition d'acceptation
par "toujours vraie" directement dans le langage machine.
D'où "SI code_session ok ALORS poursuite_execution, ...etc SINON
fin_session"
devient "SI vraie ALORS poursuite_execution, ...etc"
Bon courage quand même.
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctqbdu$j1t$1@biggoron.nerim.net...
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence
qu'il
ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou
xor, même combat.
Ce qui m'a ennuyé
(sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait
mieux
de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela
introduit des redondances ouvrant la possibilité d'attaques à chiffré
seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi
difficile l'inversion qu'une attaque à force brute. C'est du moins ce
que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
...
Mais concernant le chiffrage je pense qu'un simple xor serait
suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
...
Il faut que je m'assure des points suivants:
1 - générer une clef imprévisible de la même longueur que le clair
(une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel
pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier
par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le
fait du hasard alors ce sera effectivement inattaquable ; le défaut est
qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée
l'est à partir du clair et présentera donc des redondances avec le
chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit
servir pour le déchiffrage; celle-ci et l'identificateur de la phrase
...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor
muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec
l'attaque à clair connue qui n'a besoin que d'un nombre restreint
d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait
suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et
bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair;
mais la partie de l'algo générant (prolongeant) la clef de session
devrait être plus compliquer afin de créer des murs de feu dans
celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur
interdisant l'inversion); donc, demandant une partie algorithmique plus
compliqué (donc, à plusieurs niveaux).
J'ai fais quelques tests pour savoir le nombre de possibilités à
partir
de quelques calculs différents:
...
Par une démonstration canonique, j'ai montré qu'un problème te semblant
de l'ordre de la taille de l'univers (force brute) se réduisait, en fait,
à une résolution (force "tranquille") dont la taille n'est pas mesurable
tellement elle est petite.
...
Donc, le calcul ici qui produit le plus de caractères différents
à
partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor
(m1+k3) >
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de
possibilité
parmi les test que j'ai mentionnés au début (plus haut ici) à 4
variables différentes:
6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de
chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent
drastiquement l'espace des clés.
...
On pourrait donc supposer que si le clair comportait des caractères
différents du caractère ascii zéro, cela pourrait donner une clef à
l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère
prévisible puisque influencé par le clair qui n'est pas connu dans son
ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas
l'expliquer.
...
Je suis rendu à réfléchir si une autre variable ayant une valeur
imprévisible changeante devrait être ajoutée dans ce mur, disons une
valeur représentée par 'Var?', une valeur prise dans les caractères
de la phrase de passe, dans la clef de session ou dans le clair
lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) >
C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça
devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de
sécurité au procédé.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Moi je dirais qu'une chose, c'est que les crackeurs, ils s'embarrasent pas de trouver la clef de session mais ils remplacent la condition d'acceptation par "toujours vraie" directement dans le langage machine. D'où "SI code_session ok ALORS poursuite_execution, ...etc SINON fin_session" devient "SI vraie ALORS poursuite_execution, ...etc" Bon courage quand même.
"Christophe HENRY" a écrit dans le message de news: ctqbdu$j1t$
Autrement dit, dans l'algo de Vernam il n'y aurait aucune différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution poly-alphabétique. Addition ou xor, même combat.
Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition.
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Cela, dans l'optique où on connaît déjà l'algo, afin de rendre aussi difficile l'inversion qu'une attaque à force brute. C'est du moins ce que je conçoit.
C'est ainsi que doit se concevoir tout algorithme de chiffrement.
... Mais concernant le chiffrage je pense qu'un simple xor serait suffisant
Bonne orientation. Le tout c'est de protéger la clé de session.
... Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible. Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable ; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré, qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte. D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
4 - si les 3 premiers points
sont rencontrés, le chiffrage du clair par un simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Il n'y a pas besoin d'à-priori : xor et vernam c'est blanc-bonnet et bonnet-blanc.
Donc, un simple xor serait suffisant pour le chiffrage du clair; mais la partie de l'algo générant (prolongeant) la clef de session devrait être plus compliquer afin de créer des murs de feu dans celui-ci (dans '(Var1 + Var2) xor Var3%5' l'addition serait un mur interdisant l'inversion); donc, demandant une partie algorithmique plus compliqué (donc, à plusieurs niveaux). J'ai fais quelques tests pour savoir le nombre de possibilités à partir de quelques calculs différents: ...
Par une démonstration canonique, j'ai montré qu'un problème te semblant de l'ordre de la taille de l'univers (force brute) se réduisait, en fait, à une résolution (force "tranquille") dont la taille n'est pas mesurable tellement elle est petite.
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) > La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
... Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) > C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre. Au fur et à mesure des ajouts, ça devient plus difficile pour _moi_ de casser, mais ça n'ajoute pas de sécurité au procédé.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: ctqbdu$j1t$
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui
produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des caractères Nul (ascii zéro).
Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
Mais dans mon exemple, il n'est pas question d'une clef de session créée totalement via un mode aléatoire d'un programme ou du matériel. Car si ce serait le cas, on pourrait dire qu'à un moment donné, rendu à un certain nombre de caractères, il y aurait répétition. Mais dans mon exemple, ce n'est pas le cas puisque c'est seulement la clef de session initiale qui serait créée aléatoirement (peut-être jusqu'à un maximum de 128 caractères, donc aucun cycle qui se répète).
Le prolongement ne se fait pas non plus à partir du clair, mais à partir de la clef de session initiale. Le clair ne fait qu'influencer le calcul, ce n'est qu'un seule variable qui est utilisé à partir du clair; et le clair n'est pas connu dans son ensemble.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible.
Il me reste une variable à ajouté dont la valeur serait imprévisible à chaque fois. Je veux en donner un exemple lorsque j'aurai terminé d'y réfléchir.
Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable
Le hasard est le clair qui le fournit; le clair influence le calcul et ne construit donc pas la clef mais influence seulement le résultat, puisqu'il ne s'agit que d'une seule variable dans le lot de variables utilisées dans la formule en question.
; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré,
J'ai un exemple de clef de 16256 caractères construit à partir de 9 caractères. Et le clair n'y est pour rien puisque j'ai utilisé le caractère NUL (ascii zéro); donc le clair n'est composé que de caractère NUL, et pourtant il n'y a aucune redondances, aucun caractère inutile ou en trop.
qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
Voici ce que j'ai et vous avez dit à ce sujet:
*> en sorte que même si je donnerais les 3 premiers *> caractères du clair et de la clef cela pourrait être inutile vue le *> grand nombre d'autres caractères de la clef et du clair qui son *> inconnus de l'attaquant, et non créé par l'algo mais créé *> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré *pour connaître la clé : la taille des échantillons doit être au moins *égal à la longueur de la clé. La clé faisait trois octets, il ne m'a *donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un *clair et un chiffré d'une longeur de 100 octets, la clé faisant cette *taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis. Si vous connaissez les 5 premiers caractères de la clef et les caractères du chiffré comment alors connaître les autres caractères du clair qui n'a que 1000 caractères en tout par exemple? Aucune suite de caractères (aucun cycle) ne se répète dans la clef allant jusqu'à 16256 caractères (ici on ne parle qu'avec un clair ne comportant que des caractères NUL, mais supposons que ce ne soit pas le cas et que cela provoquerait un clef ayant plus de 16256 caractères non pareil. De toute façon dans notre exemple le clair ne comporte que 1000 caractères).
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) > La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
Il ne faut pas oublier qu'il ne s'agit pas du chiffrement avec seulement un xor mais seulement du prolongement de la clef.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) > C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre.
Je veux vous en donner un exemple lorsque j'aurai les idées plus claires là dessus. Ne pas oublier non plus que l'algo de Vernam est plus simple que linéaire et pourtant...
Bonne journée r.h.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctqbdu$j1t$1@biggoron.nerim.net...
Disons que pour le prolongement de la clef, je pense qu'il serait
mieux
de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela
introduit des redondances ouvrant la possibilité d'attaques à chiffré
seul.
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui
produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle
qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce
pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des
caractères Nul (ascii zéro).
Il faut que je m'assure des points suivants:
1 - générer une clef imprévisible de la même longueur que le clair
(une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel
pour la génération des données aléatoires.
Mais dans mon exemple, il n'est pas question d'une clef de session créée
totalement via un mode aléatoire d'un programme ou du matériel. Car si ce
serait le cas, on pourrait dire qu'à un moment donné, rendu à un certain
nombre de caractères, il y aurait répétition. Mais dans mon exemple, ce
n'est pas le cas puisque c'est seulement la clef de session initiale qui
serait créée aléatoirement (peut-être jusqu'à un maximum de 128 caractères,
donc aucun cycle qui se répète).
Le prolongement ne se fait pas non plus à partir du clair, mais à partir
de la clef de session initiale. Le clair ne fait qu'influencer le calcul,
ce n'est qu'un seule variable qui est utilisé à partir du clair; et le clair
n'est pas connu dans son ensemble.
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier
par exemple).
C'est, à mon humble avis, mission impossible.
Il me reste une variable à ajouté dont la valeur serait imprévisible à
chaque fois. Je veux en donner un exemple lorsque j'aurai terminé d'y
réfléchir.
Si le prolongement est le
fait du hasard alors ce sera effectivement inattaquable
Le hasard est le clair qui le fournit; le clair influence le calcul et
ne construit donc pas la clef mais influence seulement le résultat,
puisqu'il ne s'agit que d'une seule variable dans le lot de variables
utilisées dans la formule en question.
; le défaut est
qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée
l'est à partir du clair et présentera donc des redondances avec le
chiffré,
J'ai un exemple de clef de 16256 caractères construit à partir de 9
caractères. Et le clair n'y est pour rien puisque j'ai utilisé le caractère
NUL (ascii zéro); donc le clair n'est composé que de caractère NUL, et
pourtant il n'y a aucune redondances, aucun caractère inutile ou en trop.
qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit
servir pour le déchiffrage; celle-ci et l'identificateur de la phrase
...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor
muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
D'ailleurs, je l'ai montré avec
l'attaque à clair connue qui n'a besoin que d'un nombre restreint
d'octets du clair et du chiffré.
Voici ce que j'ai et vous avez dit à ce sujet:
*> en sorte que même si je donnerais les 3 premiers
*> caractères du clair et de la clef cela pourrait être inutile vue le
*> grand nombre d'autres caractères de la clef et du clair qui son
*> inconnus de l'attaquant, et non créé par l'algo mais créé
*> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré
*pour connaître la clé : la taille des échantillons doit être au moins
*égal à la longueur de la clé. La clé faisait trois octets, il ne m'a
*donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un
*clair et un chiffré d'une longeur de 100 octets, la clé faisant cette
*taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair
que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant
une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis.
Si vous connaissez les 5 premiers caractères de la clef et les caractères du
chiffré comment alors connaître les autres caractères du clair qui n'a que
1000 caractères en tout par exemple? Aucune suite de caractères (aucun
cycle) ne se répète dans la clef allant jusqu'à 16256 caractères (ici on ne
parle qu'avec un clair ne comportant que des caractères NUL, mais supposons
que ce ne soit pas le cas et que cela provoquerait un clef ayant plus de
16256 caractères non pareil. De toute façon dans notre exemple le clair ne
comporte que 1000 caractères).
...
Donc, le calcul ici qui produit le plus de caractères différents
à
partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor
(m1+k3) >
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que toutes
les variables soient inter reliées à quelque part; c'est ce que j'expliquais
lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est
pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez
pas capable de résoudre.
C'est justement le calcul qui donne le plus grand nombre de
possibilité
parmi les test que j'ai mentionnés au début (plus haut ici) à 4
variables différentes:
6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de
chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent
drastiquement l'espace des clés.
Il ne faut pas oublier qu'il ne s'agit pas du chiffrement avec
seulement un xor mais seulement du prolongement de la clef.
...
On pourrait donc supposer que si le clair comportait des caractères
différents du caractère ascii zéro, cela pourrait donner une clef à
l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère
prévisible puisque influencé par le clair qui n'est pas connu dans son
ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas
l'expliquer.
???
Je suis rendu à réfléchir si une autre variable ayant une valeur
imprévisible changeante devrait être ajoutée dans ce mur, disons une
valeur représentée par 'Var?', une valeur prise dans les caractères
de la phrase de passe, dans la clef de session ou dans le clair
lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) >
C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre.
Je veux vous en donner un exemple lorsque j'aurai les idées plus claires
là dessus. Ne pas oublier non plus que l'algo de Vernam est plus simple que
linéaire et pourtant...
"Christophe HENRY" a écrit dans le message de news: ctqbdu$j1t$
Disons que pour le prolongement de la clef, je pense qu'il serait mieux de mélanger les deux:
La clé n'est pas prolongée. Sa longueur augmente, certes, mais cela introduit des redondances ouvrant la possibilité d'attaques à chiffré seul.
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui
produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des caractères Nul (ascii zéro).
Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une seule clef par chiffrage).
C'est possible. Pas en VB, mais ça reste un problème d'ordre matériel pour la génération des données aléatoires.
Mais dans mon exemple, il n'est pas question d'une clef de session créée totalement via un mode aléatoire d'un programme ou du matériel. Car si ce serait le cas, on pourrait dire qu'à un moment donné, rendu à un certain nombre de caractères, il y aurait répétition. Mais dans mon exemple, ce n'est pas le cas puisque c'est seulement la clef de session initiale qui serait créée aléatoirement (peut-être jusqu'à un maximum de 128 caractères, donc aucun cycle qui se répète).
Le prolongement ne se fait pas non plus à partir du clair, mais à partir de la clef de session initiale. Le clair ne fait qu'influencer le calcul, ce n'est qu'un seule variable qui est utilisé à partir du clair; et le clair n'est pas connu dans son ensemble.
2 - construire un algo générateur de clef (de session) interdisant une attaque à clair connu (une entête connue via l'extension du fichier par exemple).
C'est, à mon humble avis, mission impossible.
Il me reste une variable à ajouté dont la valeur serait imprévisible à chaque fois. Je veux en donner un exemple lorsque j'aurai terminé d'y réfléchir.
Si le prolongement est le fait du hasard alors ce sera effectivement inattaquable
Le hasard est le clair qui le fournit; le clair influence le calcul et ne construit donc pas la clef mais influence seulement le résultat, puisqu'il ne s'agit que d'une seule variable dans le lot de variables utilisées dans la formule en question.
; le défaut est qu'il sera impossible de déchiffrer :-] Cette clé de session prolongée l'est à partir du clair et présentera donc des redondances avec le chiffré,
J'ai un exemple de clef de 16256 caractères construit à partir de 9 caractères. Et le clair n'y est pour rien puisque j'ai utilisé le caractère NUL (ascii zéro); donc le clair n'est composé que de caractère NUL, et pourtant il n'y a aucune redondances, aucun caractère inutile ou en trop.
qui lui aussi est construit à partir du clair.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
D'ailleurs, je l'ai montré avec l'attaque à clair connue qui n'a besoin que d'un nombre restreint d'octets du clair et du chiffré.
Voici ce que j'ai et vous avez dit à ce sujet:
*> en sorte que même si je donnerais les 3 premiers *> caractères du clair et de la clef cela pourrait être inutile vue le *> grand nombre d'autres caractères de la clef et du clair qui son *> inconnus de l'attaquant, et non créé par l'algo mais créé *> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré *pour connaître la clé : la taille des échantillons doit être au moins *égal à la longueur de la clé. La clé faisait trois octets, il ne m'a *donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un *clair et un chiffré d'une longeur de 100 octets, la clé faisant cette *taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis. Si vous connaissez les 5 premiers caractères de la clef et les caractères du chiffré comment alors connaître les autres caractères du clair qui n'a que 1000 caractères en tout par exemple? Aucune suite de caractères (aucun cycle) ne se répète dans la clef allant jusqu'à 16256 caractères (ici on ne parle qu'avec un clair ne comportant que des caractères NUL, mais supposons que ce ne soit pas le cas et que cela provoquerait un clef ayant plus de 16256 caractères non pareil. De toute façon dans notre exemple le clair ne comporte que 1000 caractères).
... Donc, le calcul ici qui produit le plus de caractères différents à partir soit de la clef (à 4 caractères) 2222 ou 1234 est (k1+k2) xor (m1+k3) > La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
C'est justement le calcul qui donne le plus grand nombre de possibilité parmi les test que j'ai mentionnés au début (plus haut ici) à 4 variables différentes: 6724352 possibilités: (k1+k2)xor(k3+k4)4
C'est peut-être valable tout seul, mais lorsque le procédé de chiffrement est mis en oeuvre, les redondances apparaîssent et réduisent drastiquement l'espace des clés.
Il ne faut pas oublier qu'il ne s'agit pas du chiffrement avec seulement un xor mais seulement du prolongement de la clef.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Je suis rendu à réfléchir si une autre variable ayant une valeur imprévisible changeante devrait être ajoutée dans ce mur, disons une valeur représentée par 'Var?', une valeur prise dans les caractères de la phrase de passe, dans la clef de session ou dans le clair lui-même : (k1+k2+Rép1+Var?) xor (m1+k3) > C'est inutile. Toutes tes conceptions restent dans une classe de
problèmes faciles à résoudre.
Je veux vous en donner un exemple lorsque j'aurai les idées plus claires là dessus. Ne pas oublier non plus que l'algo de Vernam est plus simple que linéaire et pourtant...
Bonne journée r.h.
Raymond H.
"Raymond H." a écrit dans le message de news: zphMd.17567$
Bonjour,
Voici ce que j'ai et vous avez dit à ce sujet: *> en sorte que même si je donnerais les 3 premiers *> caractères du clair et de la clef cela pourrait être inutile vue le *> grand nombre d'autres caractères de la clef et du clair qui son *> inconnus de l'attaquant, et non créé par l'algo mais créé *> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré *pour connaître la clé : la taille des échantillons doit être au moins *égal à la longueur de la clé. La clé faisait trois octets, il ne m'a *donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un *clair et un chiffré d'une longeur de 100 octets, la clé faisant cette *taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis.
J'aurais dû écrire: si nous possédons une clef initiale de 128 caractères non pareils, mais que vous ne connaissiez que 3 caractères du clair... alors comment faire une attaque à clair connue dans ce cas pour trouver l'ensemble du clair?
Bonne journée r.h.
"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de news:
zphMd.17567$Ck1.1392615@news20.bellglobal.com...
Bonjour,
Voici ce que j'ai et vous avez dit à ce sujet:
*> en sorte que même si je donnerais les 3 premiers
*> caractères du clair et de la clef cela pourrait être inutile vue le
*> grand nombre d'autres caractères de la clef et du clair qui son
*> inconnus de l'attaquant, et non créé par l'algo mais créé
*> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré
*pour connaître la clé : la taille des échantillons doit être au moins
*égal à la longueur de la clé. La clé faisait trois octets, il ne m'a
*donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un
*clair et un chiffré d'une longeur de 100 octets, la clé faisant cette
*taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair
que celle de la clef. Or, dans l'exemple de la clef de 9 caractères
donnant une clef prolongée à 16256 caractères ne serait pas bien utile à
mon avis.
J'aurais dû écrire: si nous possédons une clef initiale de 128
caractères non pareils, mais que vous ne connaissiez que 3 caractères du
clair... alors comment faire une attaque à clair connue dans ce cas pour
trouver l'ensemble du clair?
"Raymond H." a écrit dans le message de news: zphMd.17567$
Bonjour,
Voici ce que j'ai et vous avez dit à ce sujet: *> en sorte que même si je donnerais les 3 premiers *> caractères du clair et de la clef cela pourrait être inutile vue le *> grand nombre d'autres caractères de la clef et du clair qui son *> inconnus de l'attaquant, et non créé par l'algo mais créé *> aléatoirement au début (clef initiale).
*Voici ce qui conditionne la taille de l'échantillon du clair du chiffré *pour connaître la clé : la taille des échantillons doit être au moins *égal à la longueur de la clé. La clé faisait trois octets, il ne m'a *donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un *clair et un chiffré d'une longeur de 100 octets, la clé faisant cette *taille.
Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis.
J'aurais dû écrire: si nous possédons une clef initiale de 128 caractères non pareils, mais que vous ne connaissiez que 3 caractères du clair... alors comment faire une attaque à clair connue dans ce cas pour trouver l'ensemble du clair?
Bonne journée r.h.
Christophe HENRY
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des caractères Nul (ascii zéro). ... caractère NUL, et pourtant il n'y a aucune redondances, aucun caractère inutile ou en trop.
Fait une analyse de spectre.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
C'est un peu comme 'papa dans maman' ;-) quelque soit le sens d'où on prends le problème, il reste le même.
... Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis. Si vous connaissez les 5 premiers caractères de la clef et les caractères du chiffré comment alors connaître les autres caractères du clair qui n'a que 1000 caractères en tout par exemple?
Je "travaille" en attaque à clair connu. D'abord parce que c'est déjà suffisant pour élimer mes capacités opérationnelles, et aussi parce la doctrine affirme qu'un algo ne résistant pas à cette attaque ne vaut pas le coup.
CLair + Chiffré ======> Trouve la clé.
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à retrouver ce point.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je t'apporte : je possède des informations que je ne saurais posséder. En l'occurence, je trouve des clés alors que je ne suis pas censé les trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de problème, on communique, c'est cool... Mais je ne sais pas expliquer de manière simple ces choses. Entre êtres logiques, riguoureux et mathématiciens - en somme ceux qui te "détractent" - la convention est facile mais tu as besoin de toucher pour voir, et je ne sais pas t'aider à le faire.
Ne pas oublier non plus que l'algo de Vernam est plus simple que linéaire et pourtant...
Un volontaire pour en faire une signature de message ?
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui
produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle
qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce
pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des
caractères Nul (ascii zéro).
...
caractère NUL, et pourtant il n'y a aucune redondances, aucun
caractère inutile ou en trop.
Fait une analyse de spectre.
3 - ne conserver que la partie finale de la clef de session qui doit
servir pour le déchiffrage; celle-ci et l'identificateur de la phrase
...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor
muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
C'est un peu comme 'papa dans maman' ;-) quelque soit le sens d'où on
prends le problème, il reste le même.
...
Vous dites donc, qu'il faille une même longueur d'échantillon du
clair
que celle de la clef. Or, dans l'exemple de la clef de 9 caractères
donnant une clef prolongée à 16256 caractères ne serait pas bien
utile à mon avis. Si vous connaissez les 5 premiers caractères de la
clef et les caractères du chiffré comment alors connaître les autres
caractères du clair qui n'a que 1000 caractères en tout par exemple?
Je "travaille" en attaque à clair connu. D'abord parce que c'est déjà
suffisant pour élimer mes capacités opérationnelles, et aussi parce la
doctrine affirme qu'un algo ne résistant pas à cette attaque ne vaut pas
le coup.
CLair + Chiffré ======> Trouve la clé.
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que
toutes les variables soient inter reliées à quelque part; c'est ce que
j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se
referme et qui n'est pas coupé. J'en ai même donné la preuve avec un
exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle
j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à
retrouver ce point.
...
On pourrait donc supposer que si le clair comportait des
caractères
différents du caractère ascii zéro, cela pourrait donner une clef
à l'infini qui n'aurait aucun cycle qui se répète; donc aucun
caractère prévisible puisque influencé par le clair qui n'est pas
connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas
l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je
t'apporte : je possède des informations que je ne saurais posséder. En
l'occurence, je trouve des clés alors que je ne suis pas censé les
trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres
mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de
problème, on communique, c'est cool... Mais je ne sais pas expliquer de
manière simple ces choses.
Entre êtres logiques, riguoureux et mathématiciens - en somme ceux qui
te "détractent" - la convention est facile mais tu as besoin de toucher
pour voir, et je ne sais pas t'aider à le faire.
Ne pas oublier non plus que l'algo de Vernam est plus simple que
linéaire et pourtant...
Un volontaire pour en faire une signature de message ?
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Avec l'exemple que j'ai donné avec une clef de 9 caractères et qui produit un prolongement jusqu'à environ 16256 caractères n'ayant aucun cycle qui se répète, on ne peut pas dire qu'il y a des redondances là. N'est-ce pas? Et ceci, en prenant l'exemple d'un clair qui comporte seulement des caractères Nul (ascii zéro). ... caractère NUL, et pourtant il n'y a aucune redondances, aucun caractère inutile ou en trop.
Fait une analyse de spectre.
3 - ne conserver que la partie finale de la clef de session qui doit servir pour le déchiffrage; celle-ci et l'identificateur de la phrase ...
L'un dans l'autre, le procédé ne pourra pas être plus fort qu'un xor muni d'une clé de longueur courte.
Je ne comprends pas ce que signifie 'L'un dans l'autre'.
C'est un peu comme 'papa dans maman' ;-) quelque soit le sens d'où on prends le problème, il reste le même.
... Vous dites donc, qu'il faille une même longueur d'échantillon du clair que celle de la clef. Or, dans l'exemple de la clef de 9 caractères donnant une clef prolongée à 16256 caractères ne serait pas bien utile à mon avis. Si vous connaissez les 5 premiers caractères de la clef et les caractères du chiffré comment alors connaître les autres caractères du clair qui n'a que 1000 caractères en tout par exemple?
Je "travaille" en attaque à clair connu. D'abord parce que c'est déjà suffisant pour élimer mes capacités opérationnelles, et aussi parce la doctrine affirme qu'un algo ne résistant pas à cette attaque ne vaut pas le coup.
CLair + Chiffré ======> Trouve la clé.
La difficulté est similaire à du A+B. C'est de l'algèbre linéaire.
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à retrouver ce point.
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je t'apporte : je possède des informations que je ne saurais posséder. En l'occurence, je trouve des clés alors que je ne suis pas censé les trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de problème, on communique, c'est cool... Mais je ne sais pas expliquer de manière simple ces choses. Entre êtres logiques, riguoureux et mathématiciens - en somme ceux qui te "détractent" - la convention est facile mais tu as besoin de toucher pour voir, et je ne sais pas t'aider à le faire.
Ne pas oublier non plus que l'algo de Vernam est plus simple que linéaire et pourtant...
Un volontaire pour en faire une signature de message ?
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Christophe HENRY
J'aurais dû écrire: si nous possédons une clef initiale de 128 caractères non pareils, mais que vous ne connaissiez que 3 caractères du clair... alors comment faire une attaque à clair connue dans ce cas pour trouver l'ensemble du clair?
Comme je l'ai indiqué, si la clé (initiale) fait 128 caractères, il me faudra évidemment 128 caractères du chiffré et 128 caractères du clair, concernant la dernière attaque à clair connu réussie.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
J'aurais dû écrire: si nous possédons une clef initiale de 128
caractères non pareils, mais que vous ne connaissiez que 3 caractères du
clair... alors comment faire une attaque à clair connue dans ce cas pour
trouver l'ensemble du clair?
Comme je l'ai indiqué, si la clé (initiale) fait 128 caractères, il
me faudra évidemment 128 caractères du chiffré et 128 caractères du
clair, concernant la dernière attaque à clair connu réussie.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
J'aurais dû écrire: si nous possédons une clef initiale de 128 caractères non pareils, mais que vous ne connaissiez que 3 caractères du clair... alors comment faire une attaque à clair connue dans ce cas pour trouver l'ensemble du clair?
Comme je l'ai indiqué, si la clé (initiale) fait 128 caractères, il me faudra évidemment 128 caractères du chiffré et 128 caractères du clair, concernant la dernière attaque à clair connu réussie.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
chaton
J'ai pris quelques temps pour ruminer quelle serait la façon la plus
simple et la plus certaine de faire l'algo. J'en suis venu à la conclusion
que si le seul algo incassable est celui de Gilbert Vernam en 1917, alors
pourquoi ne pas m'en inspirer pour faire quelque chose d'aussi certain qui
lui ressemble et tout en restant autant que possible aussi simple.
Parceque c'est impossible et que cette impossibilité est démontrée mathématiquement grace a la théorie de l'information ? Tous les chiffres que tu pourras faire seront moins fiables que le chiffre de Vernam, a l'exception de ceux qui en sont des variantes et qui, tout en conservant les memes concepts, n'apporteront rien de plus que le chiffre de Vernam, tout en conservant les memes contraintes. Je te suggere une recherche sur les textes de Claude Shannon, tu comprendras pourquoi depuis ses demonstrations, les cryptographes ne cherchent plus a creer des chiffres incassables, mais des chiffres difficiles a casser.
Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une
seule clef par chiffrage).
Tu va donc implémenter un RNG vraiment aléatoire en software ? Ca risque d'en intéresser plus d'un ici ;)
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier par
exemple). 3 - ne conserver que la partie finale de la clef de session qui doit servir
pour le déchiffrage; celle-ci et l'identificateur de la phrase de passe
(généré par la phrase de passe) doivent être chiffrés ensemble par la
phrase de passe afin de les ajouter au chiffré existant. L'algo chiffrant la
phrase de passe et la clef session finale doit être aussi sûr que celui qui
génère le prolongement de la clef de session (car les 1er caractères de
la clef de session est généré aléatoirement: clef de session initiale).
Pas compris la...
4 - si les 3 premiers points sont rencontrés, le chiffrage du clair par un
simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Le principe que tu décris est celui du masque jetable, plus ou moins, la création d'un flux pour les clefs de sessions qui sont de taille identique au message à chiffrer et que tu xor avec le texte en clair. C'est identique au chiffre de Vernam sauf que tu ne pourras pas respecter le caractère aléatoire de la clef sur un ordinateur (machines probabilistes tout ca ...), tu rencontres exactement le problème qui fait que Vernam est un système idéaliste mais difficilement applicable dans la vie de tous les jours.
Je te laisse résoudre un problème: Si Vernam repose sur un chiffre plus faible, on peut en déduire qu'il n'est plus incassable. Donc, le seul moyen d'échanger la clef de session est de la transmettre en main propre, si tu la transmets par ce que l'on considère comme un canal sur selon "nos" critères actuels (c'est à dire un tunnel SSL par exemple), alors tu reviens a affaiblir TA methode puisqu'elle repose sur un systeme qui n'est plus incassable. La seule solution qui saute aux yeux, est d'utiliser Vernam pour transmettre des clefs de sessions pour ton chiffrement par Vernam. Enjoy ;)
En ces circonstances, a mon humble avis, tu devrais essayer de trouver une methode de chiffrement difficile à casser plutot que de calquer un chiffrement par Vernam, ou tenter de démontrer que les affirmations de Shannon quand à l'inexistance d'un autre algorithme incassable sont fausses (c'est plus ou moins ce que tu fais en essayant de mettre en place un algo different qui offre la meme surete).
Voili voilou, juste une opinion parmi tant d'autres, et mon post le plus long depuis au moins deux mois ;)
J'ai pris quelques temps pour ruminer quelle serait la façon la
plus
simple et la plus certaine de faire l'algo. J'en suis venu à la
conclusion
que si le seul algo incassable est celui de Gilbert Vernam en 1917,
alors
pourquoi ne pas m'en inspirer pour faire quelque chose d'aussi
certain qui
lui ressemble et tout en restant autant que possible aussi simple.
Parceque c'est impossible et que cette impossibilité est démontrée
mathématiquement grace a la théorie de l'information ? Tous les
chiffres que tu pourras faire seront moins fiables que le chiffre de
Vernam, a l'exception de ceux qui en sont des variantes et qui, tout
en conservant les memes concepts, n'apporteront rien de plus que
le chiffre de Vernam, tout en conservant les memes contraintes.
Je te suggere une recherche sur les textes de Claude Shannon, tu
comprendras pourquoi depuis ses demonstrations, les cryptographes
ne cherchent plus a creer des chiffres incassables, mais des chiffres
difficiles a casser.
Il faut que je m'assure des points suivants:
1 - générer une clef imprévisible de la même longueur que le
clair (une
seule clef par chiffrage).
Tu va donc implémenter un RNG vraiment aléatoire en software ?
Ca risque d'en intéresser plus d'un ici ;)
2 - construire un algo générateur de clef (de session) interdisant
une
attaque à clair connu (une entête connue via l'extension du
fichier par
exemple).
3 - ne conserver que la partie finale de la clef de session qui doit
servir
pour le déchiffrage; celle-ci et l'identificateur de la phrase de
passe
(généré par la phrase de passe) doivent être chiffrés ensemble
par la
phrase de passe afin de les ajouter au chiffré existant. L'algo
chiffrant la
phrase de passe et la clef session finale doit être aussi sûr que
celui qui
génère le prolongement de la clef de session (car les 1er
caractères de
la clef de session est généré aléatoirement: clef de session
initiale).
Pas compris la...
4 - si les 3 premiers points sont rencontrés, le chiffrage du clair
par un
simple xor serait suffisant pour être aussi sûr que l'algo de
Vernam.
Le principe que tu décris est celui du masque jetable, plus ou moins,
la
création d'un flux pour les clefs de sessions qui sont de taille
identique au
message à chiffrer et que tu xor avec le texte en clair. C'est
identique au
chiffre de Vernam sauf que tu ne pourras pas respecter le caractère
aléatoire de la clef sur un ordinateur (machines probabilistes tout ca
...),
tu rencontres exactement le problème qui fait que Vernam est un
système
idéaliste mais difficilement applicable dans la vie de tous les jours.
Je te laisse résoudre un problème:
Si Vernam repose sur un chiffre plus faible, on peut en déduire qu'il
n'est
plus incassable. Donc, le seul moyen d'échanger la clef de session est
de la transmettre en main propre, si tu la transmets par ce que l'on
considère comme un canal sur selon "nos" critères actuels (c'est à
dire
un tunnel SSL par exemple), alors tu reviens a affaiblir TA methode
puisqu'elle repose sur un systeme qui n'est plus incassable. La seule
solution qui saute aux yeux, est d'utiliser Vernam pour transmettre des
clefs de sessions pour ton chiffrement par Vernam. Enjoy ;)
En ces circonstances, a mon humble avis, tu devrais essayer de trouver
une methode de chiffrement difficile à casser plutot que de calquer un
chiffrement par Vernam, ou tenter de démontrer que les affirmations de
Shannon quand à l'inexistance d'un autre algorithme incassable sont
fausses (c'est plus ou moins ce que tu fais en essayant de mettre en
place un algo different qui offre la meme surete).
Voili voilou, juste une opinion parmi tant d'autres, et mon post le
plus long
depuis au moins deux mois ;)
J'ai pris quelques temps pour ruminer quelle serait la façon la plus
simple et la plus certaine de faire l'algo. J'en suis venu à la conclusion
que si le seul algo incassable est celui de Gilbert Vernam en 1917, alors
pourquoi ne pas m'en inspirer pour faire quelque chose d'aussi certain qui
lui ressemble et tout en restant autant que possible aussi simple.
Parceque c'est impossible et que cette impossibilité est démontrée mathématiquement grace a la théorie de l'information ? Tous les chiffres que tu pourras faire seront moins fiables que le chiffre de Vernam, a l'exception de ceux qui en sont des variantes et qui, tout en conservant les memes concepts, n'apporteront rien de plus que le chiffre de Vernam, tout en conservant les memes contraintes. Je te suggere une recherche sur les textes de Claude Shannon, tu comprendras pourquoi depuis ses demonstrations, les cryptographes ne cherchent plus a creer des chiffres incassables, mais des chiffres difficiles a casser.
Il faut que je m'assure des points suivants: 1 - générer une clef imprévisible de la même longueur que le clair (une
seule clef par chiffrage).
Tu va donc implémenter un RNG vraiment aléatoire en software ? Ca risque d'en intéresser plus d'un ici ;)
2 - construire un algo générateur de clef (de session) interdisant une
attaque à clair connu (une entête connue via l'extension du fichier par
exemple). 3 - ne conserver que la partie finale de la clef de session qui doit servir
pour le déchiffrage; celle-ci et l'identificateur de la phrase de passe
(généré par la phrase de passe) doivent être chiffrés ensemble par la
phrase de passe afin de les ajouter au chiffré existant. L'algo chiffrant la
phrase de passe et la clef session finale doit être aussi sûr que celui qui
génère le prolongement de la clef de session (car les 1er caractères de
la clef de session est généré aléatoirement: clef de session initiale).
Pas compris la...
4 - si les 3 premiers points sont rencontrés, le chiffrage du clair par un
simple xor serait suffisant pour être aussi sûr que l'algo de Vernam.
Le principe que tu décris est celui du masque jetable, plus ou moins, la création d'un flux pour les clefs de sessions qui sont de taille identique au message à chiffrer et que tu xor avec le texte en clair. C'est identique au chiffre de Vernam sauf que tu ne pourras pas respecter le caractère aléatoire de la clef sur un ordinateur (machines probabilistes tout ca ...), tu rencontres exactement le problème qui fait que Vernam est un système idéaliste mais difficilement applicable dans la vie de tous les jours.
Je te laisse résoudre un problème: Si Vernam repose sur un chiffre plus faible, on peut en déduire qu'il n'est plus incassable. Donc, le seul moyen d'échanger la clef de session est de la transmettre en main propre, si tu la transmets par ce que l'on considère comme un canal sur selon "nos" critères actuels (c'est à dire un tunnel SSL par exemple), alors tu reviens a affaiblir TA methode puisqu'elle repose sur un systeme qui n'est plus incassable. La seule solution qui saute aux yeux, est d'utiliser Vernam pour transmettre des clefs de sessions pour ton chiffrement par Vernam. Enjoy ;)
En ces circonstances, a mon humble avis, tu devrais essayer de trouver une methode de chiffrement difficile à casser plutot que de calquer un chiffrement par Vernam, ou tenter de démontrer que les affirmations de Shannon quand à l'inexistance d'un autre algorithme incassable sont fausses (c'est plus ou moins ce que tu fais en essayant de mettre en place un algo different qui offre la meme surete).
Voili voilou, juste une opinion parmi tant d'autres, et mon post le plus long depuis au moins deux mois ;)
Raymond H.
"Raymond H." a écrit dans le message de news: S40Md.8049$
Bonjour, J'avais oublié de donner un petit exemple de données chiffrées.
(k1+k2) xor (m1+k3)= donne le caractère à ajouter à la fin de la clef pour la prolonger. m1 xor k1Á (c1 = donnée chiffrée)
ki#4=(ascii:) 50-51-52 = clef de session initiale m¸J#%P9 =(ascii:) 98-56-74-35-36-80-57 =clair, données à chiffrer k=(ascii:) 050-051-052-243-076-177-235-237-161-002 = clef de session prolongée
kf=(ascii:) 243-076-177-235-237-161-002 = clef de session finale à conserver pour être chiffrée
Ici, j'avais écris un peu trop vite. Je corrige l'exemple ci-dessus:
- k=(ascii:) 050-051-052-243-076-177-235-237-161 = clef de session prolongée
- la clef de session finale à conserver est "235-237-161". De la même longueur que la clef de session initiale.
r.h.
Voilà!
Raymond H.
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: ctsqok$1qhj$
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à retrouver ce point.
Je rectifie. Il ne s'agissait pas d'attaque à clair connue mais de
calcul à partir seulement de l'algo.
<<<<<<<<<<<<<<<
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.
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). ...
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 :
<<<<<<<<<<<<<<<
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je t'apporte : je possède des informations que je ne saurais posséder. En l'occurence, je trouve des clés alors que je ne suis pas censé les trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de problème, on communique, c'est cool... Mais je ne sais pas expliquer de manière simple ces choses.
Il y a aussi des cas où c'est l'intuition qui révèle certaines choses. C'est mon cas avec mon exemple de la roue dont le cycle est coupé.
Bonne journée r.h.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctsqok$1qhj$1@biggoron.nerim.net...
Pour que l'algèbre puisse trouver toutes les données il faut que
toutes les variables soient inter reliées à quelque part; c'est ce que
j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se
referme et qui n'est pas coupé. J'en ai même donné la preuve avec un
exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle
j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à
retrouver ce point.
Je rectifie. Il ne s'agissait pas d'attaque à clair connue mais de
calcul à partir seulement de l'algo.
<<<<<<<<<<<<<<<
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.
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).
...
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 :
<<<<<<<<<<<<<<<
...
On pourrait donc supposer que si le clair comportait des
caractères
différents du caractère ascii zéro, cela pourrait donner une clef
à l'infini qui n'aurait aucun cycle qui se répète; donc aucun
caractère prévisible puisque influencé par le clair qui n'est pas
connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas
l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je
t'apporte : je possède des informations que je ne saurais posséder. En
l'occurence, je trouve des clés alors que je ne suis pas censé les
trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres
mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de
problème, on communique, c'est cool... Mais je ne sais pas expliquer de
manière simple ces choses.
Il y a aussi des cas où c'est l'intuition qui révèle certaines choses.
C'est mon cas avec mon exemple de la roue dont le cycle est coupé.
"Christophe HENRY" a écrit dans le message de news: ctsqok$1qhj$
Pour que l'algèbre puisse trouver toutes les données il faut que toutes les variables soient inter reliées à quelque part; c'est ce que j'expliquais lorsque je donnais l'exemple d'un cycle de roue qui se referme et qui n'est pas coupé. J'en ai même donné la preuve avec un exemple dont vous n'étiez pas capable de résoudre.
Référence ? Je n'ai pas de souvenir d'attaque à clair connu à laquelle j'ai échoué. Vu la longueur de nos discussions, je ne parviens pas à retrouver ce point.
Je rectifie. Il ne s'agissait pas d'attaque à clair connue mais de
calcul à partir seulement de l'algo.
<<<<<<<<<<<<<<<
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.
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). ...
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 :
<<<<<<<<<<<<<<<
... On pourrait donc supposer que si le clair comportait des caractères différents du caractère ascii zéro, cela pourrait donner une clef à l'infini qui n'aurait aucun cycle qui se répète; donc aucun caractère prévisible puisque influencé par le clair qui n'est pas connu dans son ensemble.
J'ai la théorie pour être convaincu du contraire mais je ne sais pas l'expliquer.
???
Tu avances dans ton étude grâces aux preuves irréfutables que je t'apporte : je possède des informations que je ne saurais posséder. En l'occurence, je trouve des clés alors que je ne suis pas censé les trouver.
Le problème est qu'ici ma démonstration (enfin, celle d'illustres mathématiciens) s'appuie sur des bases que tu ne possèdes pas. Pas de problème, on communique, c'est cool... Mais je ne sais pas expliquer de manière simple ces choses.
Il y a aussi des cas où c'est l'intuition qui révèle certaines choses. C'est mon cas avec mon exemple de la roue dont le cycle est coupé.
