"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)=
"Christophe HENRY" a écrit dans le message de news: ctsqri$1qhj$
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.
Oui. Dans mon dernier exemple, qui ne fait qu'un xor entre le clair et le chiffré cela est évident. Je me demandais si ça ne serait pas mieux de compliquer le calcul de ce dernier (xor entre caractères du clair en plus lors du chiffrage) mais si je le fais cela augmenterais le nombre de possibilités de clefs pour trouver le chiffré via l'algo. Je vais donc, m'attarder à rendre imprévisible la clef elle-même soit par choix de calculs aléatoirement (dépendant de la valeur qui suis dans la clef) ou par permutation de groupe de caractères de la clef.
a+ r.h.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctsqri$1qhj$2@biggoron.nerim.net...
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.
Oui. Dans mon dernier exemple, qui ne fait qu'un xor entre le clair et
le chiffré cela est évident. Je me demandais si ça ne serait pas mieux de
compliquer le calcul de ce dernier (xor entre caractères du clair en plus
lors du chiffrage) mais si je le fais cela augmenterais le nombre de
possibilités de clefs pour trouver le chiffré via l'algo. Je vais donc,
m'attarder à rendre imprévisible la clef elle-même soit par choix de calculs
aléatoirement (dépendant de la valeur qui suis dans la clef) ou par
permutation de groupe de caractères de la clef.
"Christophe HENRY" a écrit dans le message de news: ctsqri$1qhj$
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.
Oui. Dans mon dernier exemple, qui ne fait qu'un xor entre le clair et le chiffré cela est évident. Je me demandais si ça ne serait pas mieux de compliquer le calcul de ce dernier (xor entre caractères du clair en plus lors du chiffrage) mais si je le fais cela augmenterais le nombre de possibilités de clefs pour trouver le chiffré via l'algo. Je vais donc, m'attarder à rendre imprévisible la clef elle-même soit par choix de calculs aléatoirement (dépendant de la valeur qui suis dans la clef) ou par permutation de groupe de caractères de la clef.
a+ r.h.
Raymond H.
Bonjour,
"chaton" a écrit dans le message de news:
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
Je vais chercher ce que Claude Shannon dit là dessus.
-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 ?
Ce serait seulement la clef initiale et non la clef au complet. En plus, la création de la clef initiale pourrait être influencée par la phrase de passe.
-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...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici :-)
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
En effet, c'est un masque jetable puisqu'une même clef n'est utilisée qu'une seule fois.
-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
Oui.
- sauf que tu ne pourras pas respecter le caractère -aléatoire de la clef sur un ordinateur (machines probabilistes tout ca -...),
C'est pour cela que c'est seulement les premiers caractères de la clef de session qui sont créées aléatoirement mais seraient influencées par la phrase de passe.
Le restant de la clef serait créé par l'algo mais aussi influencée par le clair. On ne conserve que la clef de session finale (du même nombre de caractères que la clef de session initiale).
-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.
Dépendant de ce que 'plus faible' signifie ici.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de session initiale. Ce serait seulement la clef de session finale qui serait crypté et transmisse avec le chiffré. C'est la phrase de passe qui déchiffre (indépendamment) la clef de session finale, cela afin d'être utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait utiliser toujours la même phrase de passe mais la clef de session ne serait jamais la même.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le même: xor entre clair et chiffré. Ce qui serait semblable est le masque jetable.
- 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 ;)
:-) Bonne journée r.h.
Bonjour,
"chaton" <chaton@tristeza.org> a écrit dans le message de news:
1107463692.446852.302720@c13g2000cwb.googlegroups.com...
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
Je vais chercher ce que Claude Shannon dit là dessus.
-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 ?
Ce serait seulement la clef initiale et non la clef au complet. En
plus, la création de la clef initiale pourrait être influencée par la phrase
de passe.
-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...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici
:-)
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
En effet, c'est un masque jetable puisqu'une même clef n'est utilisée
qu'une seule fois.
-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
Oui.
- sauf que tu ne pourras pas respecter le caractère
-aléatoire de la clef sur un ordinateur (machines probabilistes tout ca
-...),
C'est pour cela que c'est seulement les premiers caractères de la clef
de session qui sont créées aléatoirement mais seraient influencées par la
phrase de passe.
Le restant de la clef serait créé par l'algo mais aussi influencée par le
clair. On ne conserve que la clef de session finale (du même nombre de
caractères que la clef de session initiale).
-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.
Dépendant de ce que 'plus faible' signifie ici.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de
session initiale. Ce serait seulement la clef de session finale qui serait
crypté et transmisse avec le chiffré. C'est la phrase de passe qui
déchiffre (indépendamment) la clef de session finale, cela afin d'être
utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait
utiliser toujours la même phrase de passe mais la clef de session ne serait
jamais la même.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le
même: xor entre clair et chiffré. Ce qui serait semblable est le masque
jetable.
- 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
Je vais chercher ce que Claude Shannon dit là dessus.
-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 ?
Ce serait seulement la clef initiale et non la clef au complet. En plus, la création de la clef initiale pourrait être influencée par la phrase de passe.
-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...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici :-)
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
En effet, c'est un masque jetable puisqu'une même clef n'est utilisée qu'une seule fois.
-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
Oui.
- sauf que tu ne pourras pas respecter le caractère -aléatoire de la clef sur un ordinateur (machines probabilistes tout ca -...),
C'est pour cela que c'est seulement les premiers caractères de la clef de session qui sont créées aléatoirement mais seraient influencées par la phrase de passe.
Le restant de la clef serait créé par l'algo mais aussi influencée par le clair. On ne conserve que la clef de session finale (du même nombre de caractères que la clef de session initiale).
-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.
Dépendant de ce que 'plus faible' signifie ici.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de session initiale. Ce serait seulement la clef de session finale qui serait crypté et transmisse avec le chiffré. C'est la phrase de passe qui déchiffre (indépendamment) la clef de session finale, cela afin d'être utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait utiliser toujours la même phrase de passe mais la clef de session ne serait jamais la même.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le même: xor entre clair et chiffré. Ce qui serait semblable est le masque jetable.
- 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 ;)
:-) Bonne journée r.h.
chaton
On 2005-02-03, Raymond H. wrote:
-Tu va donc implémenter un RNG vraiment aléatoire en software ?
Ce serait seulement la clef initiale et non la clef au complet. En plus, la création de la clef initiale pourrait être influencée par la phrase de passe.
J'ai bien compris, mais cela n'enleve en rien la complexite d'implementation d'un generateur aleatoire (pour offrir la surete d'un Vernam, tu ne peux pas te contenter de pseudo-aleatoire) sur une machine deterministe.
Tu ne peux pas faire entrer en ligne de compte l'alea dans ton algo parceque d'une part la qualite de celui ci depends de sa source (ton algo est donc plus ou moins affaibli selon la source d'entropie) alors que l'on attends d' un algo qu'il soit sur (et pas incassable) inconditionnellement.
Je ne sais plus ou j'ai pu lire cette phrase, mais de memoire ca donnait:
"un algorithme fiable doit etre considere comme sur independamment du mode utilise".
Ce qui est le cas pour Rijndael/AES, l'ajout d'alea dans l'un des modes a effet retroactif ajoute certe une securite, mais l'algo etant fiable independamment du mode, une source d'alea a faible entropie n'abaisse pas la securite que fourni l'algo (d'un certain point de vue). Je parle de Rijndael comme je parle d'autres algos connus, c'est juste le premier auquel j'ai pense ;)
-Pas compris la...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici :-)
Je t'avouerais que j'ai la flemme de remonter lire d'autres messages ;)
[...]
C'est pour cela que c'est seulement les premiers caractères de la clef de session qui sont créées aléatoirement mais seraient influencées par la phrase de passe.
Il n'en demeure pas moins que la qualite de l'alea rentre en compte puisque je suppose qu'a un moment ou a un autre un xor sera fait entre ton alea et ta phrase de passe. Si ta source d'alea est de mauvaise qualite, alors il deviendra possible d'annuler le xor avec plus ou moins de travail.
[...]
-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.
Dépendant de ce que 'plus faible' signifie ici.
Des lors qu'il n'est pas incassable, il est considere comme plus faible. Si un chiffre garanti etre incassable, qu'il repose en partie sur un chiffre cassable (meme en un temps hors de portee) alors de facto ton algorithme n'est plus incassable, c'est le principe du maillon le plus faible de la chaine.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de session initiale. Ce serait seulement la clef de session finale qui serait crypté et transmisse avec le chiffré. C'est la phrase de passe qui déchiffre (indépendamment) la clef de session finale, cela afin d'être utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait utiliser toujours la même phrase de passe mais la clef de session ne serait jamais la même.
Encore une fois, le probleme se situe la. Tu ne peux pas offrir la securite de Vernam puisque ne serait-ce que pour le partage de la phrase de passe tu es oblige a un moment ou a un autre de passer par un tunnel non protege par un chiffre de Vernam et ne garantissant donc pas une securite totale. Quand a la reutilisation de la phrase de passe, on en revient a la qualite de ton aleatoire qui, encore une fois selon mon humble avis, ne doit pas etre prise en compte dans la conception d'un algo mais doit se placer a un niveau superieur.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le même: xor entre clair et chiffré. Ce qui serait semblable est le masque jetable.
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne change rien a la methode sous-jacente et a ses caracteristiques particulieres (cf. shannon encore lui ;).
-- chaton@
On 2005-02-03, Raymond H. <divers_rh@hotmail.com> wrote:
-Tu va donc implémenter un RNG vraiment aléatoire en software ?
Ce serait seulement la clef initiale et non la clef au complet. En
plus, la création de la clef initiale pourrait être influencée par la phrase
de passe.
J'ai bien compris, mais cela n'enleve en rien la complexite d'implementation
d'un generateur aleatoire (pour offrir la surete d'un Vernam, tu ne peux pas
te contenter de pseudo-aleatoire) sur une machine deterministe.
Tu ne peux pas faire entrer en ligne de compte l'alea dans ton algo parceque
d'une part la qualite de celui ci depends de sa source (ton algo est donc
plus ou moins affaibli selon la source d'entropie) alors que l'on attends d'
un algo qu'il soit sur (et pas incassable) inconditionnellement.
Je ne sais plus ou j'ai pu lire cette phrase, mais de memoire ca donnait:
"un algorithme fiable doit etre considere comme sur independamment du mode
utilise".
Ce qui est le cas pour Rijndael/AES, l'ajout d'alea dans l'un des modes
a effet retroactif ajoute certe une securite, mais l'algo etant fiable
independamment du mode, une source d'alea a faible entropie n'abaisse pas
la securite que fourni l'algo (d'un certain point de vue). Je parle de
Rijndael comme je parle d'autres algos connus, c'est juste le premier
auquel j'ai pense ;)
-Pas compris la...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici
:-)
Je t'avouerais que j'ai la flemme de remonter lire d'autres messages ;)
[...]
C'est pour cela que c'est seulement les premiers caractères de la clef
de session qui sont créées aléatoirement mais seraient influencées par la
phrase de passe.
Il n'en demeure pas moins que la qualite de l'alea rentre en compte puisque
je suppose qu'a un moment ou a un autre un xor sera fait entre ton alea
et ta phrase de passe. Si ta source d'alea est de mauvaise qualite, alors
il deviendra possible d'annuler le xor avec plus ou moins de travail.
[...]
-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.
Dépendant de ce que 'plus faible' signifie ici.
Des lors qu'il n'est pas incassable, il est considere comme plus faible.
Si un chiffre garanti etre incassable, qu'il repose en partie sur un
chiffre cassable (meme en un temps hors de portee) alors de facto ton
algorithme n'est plus incassable, c'est le principe du maillon le plus
faible de la chaine.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de
session initiale. Ce serait seulement la clef de session finale qui serait
crypté et transmisse avec le chiffré. C'est la phrase de passe qui
déchiffre (indépendamment) la clef de session finale, cela afin d'être
utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait
utiliser toujours la même phrase de passe mais la clef de session ne serait
jamais la même.
Encore une fois, le probleme se situe la. Tu ne peux pas offrir la securite
de Vernam puisque ne serait-ce que pour le partage de la phrase de passe tu
es oblige a un moment ou a un autre de passer par un tunnel non protege par
un chiffre de Vernam et ne garantissant donc pas une securite totale.
Quand a la reutilisation de la phrase de passe, on en revient a la qualite
de ton aleatoire qui, encore une fois selon mon humble avis, ne doit pas
etre prise en compte dans la conception d'un algo mais doit se placer a un
niveau superieur.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le
même: xor entre clair et chiffré. Ce qui serait semblable est le masque
jetable.
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le
fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne
change rien a la methode sous-jacente et a ses caracteristiques particulieres
(cf. shannon encore lui ;).
-Tu va donc implémenter un RNG vraiment aléatoire en software ?
Ce serait seulement la clef initiale et non la clef au complet. En plus, la création de la clef initiale pourrait être influencée par la phrase de passe.
J'ai bien compris, mais cela n'enleve en rien la complexite d'implementation d'un generateur aleatoire (pour offrir la surete d'un Vernam, tu ne peux pas te contenter de pseudo-aleatoire) sur une machine deterministe.
Tu ne peux pas faire entrer en ligne de compte l'alea dans ton algo parceque d'une part la qualite de celui ci depends de sa source (ton algo est donc plus ou moins affaibli selon la source d'entropie) alors que l'on attends d' un algo qu'il soit sur (et pas incassable) inconditionnellement.
Je ne sais plus ou j'ai pu lire cette phrase, mais de memoire ca donnait:
"un algorithme fiable doit etre considere comme sur independamment du mode utilise".
Ce qui est le cas pour Rijndael/AES, l'ajout d'alea dans l'un des modes a effet retroactif ajoute certe une securite, mais l'algo etant fiable independamment du mode, une source d'alea a faible entropie n'abaisse pas la securite que fourni l'algo (d'un certain point de vue). Je parle de Rijndael comme je parle d'autres algos connus, c'est juste le premier auquel j'ai pense ;)
-Pas compris la...
C'est expliqué dans d'autres messages. Un peu long à ré expliquer ici :-)
Je t'avouerais que j'ai la flemme de remonter lire d'autres messages ;)
[...]
C'est pour cela que c'est seulement les premiers caractères de la clef de session qui sont créées aléatoirement mais seraient influencées par la phrase de passe.
Il n'en demeure pas moins que la qualite de l'alea rentre en compte puisque je suppose qu'a un moment ou a un autre un xor sera fait entre ton alea et ta phrase de passe. Si ta source d'alea est de mauvaise qualite, alors il deviendra possible d'annuler le xor avec plus ou moins de travail.
[...]
-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.
Dépendant de ce que 'plus faible' signifie ici.
Des lors qu'il n'est pas incassable, il est considere comme plus faible. Si un chiffre garanti etre incassable, qu'il repose en partie sur un chiffre cassable (meme en un temps hors de portee) alors de facto ton algorithme n'est plus incassable, c'est le principe du maillon le plus faible de la chaine.
- 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 ;)
La clef de session n'est pas transmise à vraie dire, ni la clef de session initiale. Ce serait seulement la clef de session finale qui serait crypté et transmisse avec le chiffré. C'est la phrase de passe qui déchiffre (indépendamment) la clef de session finale, cela afin d'être utilisée pour le déchiffrage en inversant l'algo. Donc, on pourrait utiliser toujours la même phrase de passe mais la clef de session ne serait jamais la même.
Encore une fois, le probleme se situe la. Tu ne peux pas offrir la securite de Vernam puisque ne serait-ce que pour le partage de la phrase de passe tu es oblige a un moment ou a un autre de passer par un tunnel non protege par un chiffre de Vernam et ne garantissant donc pas une securite totale. Quand a la reutilisation de la phrase de passe, on en revient a la qualite de ton aleatoire qui, encore une fois selon mon humble avis, ne doit pas etre prise en compte dans la conception d'un algo mais doit se placer a un niveau superieur.
-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,
Ce n'est pas vraiment un calquage bien que le chiffrage pourrait être le même: xor entre clair et chiffré. Ce qui serait semblable est le masque jetable.
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne change rien a la methode sous-jacente et a ses caracteristiques particulieres (cf. shannon encore lui ;).
-- chaton@
Christophe HENRY
... (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). ... 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é.
C'un cas typique de débat perpetuel fondé sur l'inspiration divine. Le problème, c'est que je ne comprends pas ce type d'allégation. Là où tu vois un mouvement circulaire, je ne vois qu'une relation déjà établie entre variables et sans surprise.
Compare la résolution d'un système équation classique avec la méthode de Gauss, qui reprends donc l'allégorie de la roue, avec la résolution bête et méchante par le calcul matriciel.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
...
(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).
...
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é.
C'un cas typique de débat perpetuel fondé sur l'inspiration divine. Le
problème, c'est que je ne comprends pas ce type d'allégation. Là où tu
vois un mouvement circulaire, je ne vois qu'une relation déjà
établie entre variables et sans surprise.
Compare la résolution d'un système équation classique avec la méthode
de Gauss, qui reprends donc l'allégorie de la roue, avec la résolution
bête et méchante par le calcul matriciel.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
... (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). ... 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é.
C'un cas typique de débat perpetuel fondé sur l'inspiration divine. Le problème, c'est que je ne comprends pas ce type d'allégation. Là où tu vois un mouvement circulaire, je ne vois qu'une relation déjà établie entre variables et sans surprise.
Compare la résolution d'un système équation classique avec la méthode de Gauss, qui reprends donc l'allégorie de la roue, avec la résolution bête et méchante par le calcul matriciel.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Christophe HENRY
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne change rien a la methode sous-jacente et a ses caracteristiques particulieres (cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le xor n'a que le zero et le un.
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les sorcière Halliwel ;-)
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le
fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne
change rien a la methode sous-jacente et a ses caracteristiques particulieres
(cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce
dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le xor
n'a que le zero et le un.
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les
sorcière Halliwel ;-)
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne change rien a la methode sous-jacente et a ses caracteristiques particulieres (cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le xor n'a que le zero et le un.
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les sorcière Halliwel ;-)
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: ctvd6b$2u3l$
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
Vous savez, ce n'est pas obligatoirement d'une inspiration divine qu'une intuition est; elle pourrait aussi bien être diabolique (ici je n'entre pas dans un débat) ou bien de la partie du cerveau sous le cortex cérébral. Celui qui a réussi le premier à former une image en mouvement (la télé) avait une certaine intuition qui l'a amené plus avant dans ses recherches pour aboutir au résultat 'surprenant' (l'image transmisse et reçue via les ondes). Sans intuition et sans imagination le progrès peut être très ralenti. Moi, mon intuition me dit qu'un système incassable est possible et c'est pour cela que je continue à avancer dans mes recherches. Mais je ne prétends aucunement que je vais réussir à trouver.
Bonne journée :-)
r.h.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctvd6b$2u3l$1@biggoron.nerim.net...
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
Vous savez, ce n'est pas obligatoirement d'une inspiration divine qu'une
intuition est; elle pourrait aussi bien être diabolique (ici je n'entre pas
dans un débat) ou bien de la partie du cerveau sous le cortex cérébral.
Celui qui a réussi le premier à former une image en mouvement (la télé)
avait une certaine intuition qui l'a amené plus avant dans ses recherches
pour aboutir au résultat 'surprenant' (l'image transmisse et reçue via les
ondes).
Sans intuition et sans imagination le progrès peut être très ralenti.
Moi, mon intuition me dit qu'un système incassable est possible et c'est
pour cela que je continue à avancer dans mes recherches. Mais je ne
prétends aucunement que je vais réussir à trouver.
"Christophe HENRY" a écrit dans le message de news: ctvd6b$2u3l$
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
Vous savez, ce n'est pas obligatoirement d'une inspiration divine qu'une intuition est; elle pourrait aussi bien être diabolique (ici je n'entre pas dans un débat) ou bien de la partie du cerveau sous le cortex cérébral. Celui qui a réussi le premier à former une image en mouvement (la télé) avait une certaine intuition qui l'a amené plus avant dans ses recherches pour aboutir au résultat 'surprenant' (l'image transmisse et reçue via les ondes). Sans intuition et sans imagination le progrès peut être très ralenti. Moi, mon intuition me dit qu'un système incassable est possible et c'est pour cela que je continue à avancer dans mes recherches. Mais je ne prétends aucunement que je vais réussir à trouver.
Bonne journée :-)
r.h.
chaton
Christophe HENRY wrote:
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le
fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne
change rien a la methode sous-jacente et a ses caracteristiques particulieres
(cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le xor
n'a que le zero et le un.
vi, on est bien d'accord, ma phrase etait peut etre un peu mal tournee mais il faudra mettre ca sur le compte de la fatigue ;-)
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les sorcière Halliwel ;-)
Elle avait pas la meme gueule hein ;-)
Christophe HENRY wrote:
Hm, pour moi le chiffre de Vernam et le masque jetable sont
similaires, le
fait que l'un se base sur le polyalphabetisme et l'autre sur un xor
ne
change rien a la methode sous-jacente et a ses caracteristiques
particulieres
(cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce
dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le
xor
n'a que le zero et le un.
vi, on est bien d'accord, ma phrase etait peut etre un peu mal tournee
mais il faudra mettre ca sur le compte de la fatigue ;-)
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les
sorcière Halliwel ;-)
Hm, pour moi le chiffre de Vernam et le masque jetable sont similaires, le
fait que l'un se base sur le polyalphabetisme et l'autre sur un xor ne
change rien a la methode sous-jacente et a ses caracteristiques particulieres
(cf. shannon encore lui ;).
En fait, le xor est un chiffre polyalphabétique comme le Vernam. Ce dernier s'appuie sur un alphabet de 26 ou 256 lettres tandis que le xor
n'a que le zero et le un.
vi, on est bien d'accord, ma phrase etait peut etre un peu mal tournee mais il faudra mettre ca sur le compte de la fatigue ;-)
Shannon, j'aimait bien quand elle jouait dans Beverly hills ou Les sorcière Halliwel ;-)
Elle avait pas la meme gueule hein ;-)
Christophe HENRY
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
... Moi, mon intuition me dit qu'un système incassable est possible et c'est pour cela que je continue à avancer dans mes recherches. Mais je ne prétends aucunement que je vais réussir à trouver.
Il a été démontré qu'il n'y avait pas de solution au problème du système incassable (sauf xor). Ni trouvable, ni prouvable. Ce n'est pas une idée, c'est une démonstration. Depuis fort longtemps on ne cherche plus à faire de l'incassable, on fait du difficilement cassable.
Bon, des gens plus informés que moi ont fait ces démonstrations et je suis bêtement (je comprends un peu :-) leurs conclusions :-) Mon intuition pourraît être définie comme "je pense qu'ils ont raison", mais je ne sais pas l'exposer clairement _ici_. Il existe par contre des ouvrages redoutables sur la question.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
...
Moi, mon intuition me dit qu'un système incassable est possible et
c'est pour cela que je continue à avancer dans mes recherches. Mais je
ne prétends aucunement que je vais réussir à trouver.
Il a été démontré qu'il n'y avait pas de solution au problème du
système incassable (sauf xor). Ni trouvable, ni prouvable. Ce n'est pas
une idée, c'est une démonstration. Depuis fort longtemps on ne cherche
plus à faire de l'incassable, on fait du difficilement cassable.
Bon, des gens plus informés que moi ont fait ces démonstrations et je
suis bêtement (je comprends un peu :-) leurs conclusions :-) Mon
intuition pourraît être définie comme "je pense qu'ils ont raison",
mais je ne sais pas l'exposer clairement _ici_.
Il existe par contre des ouvrages redoutables sur la question.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
C'un cas typique de débat perpetuel fondé sur l'inspiration divine.
... Moi, mon intuition me dit qu'un système incassable est possible et c'est pour cela que je continue à avancer dans mes recherches. Mais je ne prétends aucunement que je vais réussir à trouver.
Il a été démontré qu'il n'y avait pas de solution au problème du système incassable (sauf xor). Ni trouvable, ni prouvable. Ce n'est pas une idée, c'est une démonstration. Depuis fort longtemps on ne cherche plus à faire de l'incassable, on fait du difficilement cassable.
Bon, des gens plus informés que moi ont fait ces démonstrations et je suis bêtement (je comprends un peu :-) leurs conclusions :-) Mon intuition pourraît être définie comme "je pense qu'ils ont raison", mais je ne sais pas l'exposer clairement _ici_. Il existe par contre des ouvrages redoutables sur la question.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: ctsqok$1qhj$
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é.
Je viens de trouver une solution pour tenter d'éliminer la possibilité d'une attaque à clair connu (donc, via un en-tête connu à cause de l'extension du nom du fichier).
Avant de chiffrer avec un xor, je fais une permutation du clair par groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les 10 choix disponibles de permutation pour les 8 caractères qui précèdent ce 9e caractère. Donc, le choix de permutation est imprévisible. Ensuite seulement, on chiffre.
Donc, on additionne chacun des 8 caractères selon la valeur du rang de chaque caractère dans la chaîne. Ceci pour aider à éviter qu'un cycle recommence si le clair n'est composé que des caractères ascii zéro.
Exemple de clair en ascii:
050-023-045-112-124-084-045-056-056 = clair 1
+
001-002-003-004-005-006-007-008-009-... = valeur à additionner
051-025-048-116-129-090-051-064-065 =clair 2
Ensuite, on fait la permutation par groupe de 8 caractères à tous les 4 caractères. On débute du caractère 1 à 8, puis de 5 à 12, de 9 à 16, de 13 à 20, etc.
Voici les 10 choix de permutation. On change donc l'ordre des 8 caractères à permuter (1er, 2e, 3e ,4e, 5e, 6e, 7e, 8e, 9e, 10e)
0) 8-1-7-2-6-3-5-4
Ici le 8e caractère du 'clair 2' deviendrait le 1er dans le 'clair 3'; le 1er deviendrait le 2e, le 7e deviendrait le 3e, etc.
1) 2-4-6-8-1-3-5-7
2) 1-3-5-7-2-4-6-8
3) 1-4-7-2-5-8-3-6
4) 2-1-4-3-6-5-8-7
5) 3-2-5-4-7-6-1-8
6) 4-3-2-1-8-7-6-5
7) 4-5-3-6-2-7-1-8
8) 5-4-6-3-7-2-8-1
9) 1-8-2-7-3-6-4-5
Exemple:
Le 9e caractère du 'clair 2' est 065. Le chiffre de droite de ce 9e caractère ascii est 5. Donc, on permute avec la permutation numéro 5, c'est-à-dire selon cet ordre: 3-2-5-4-7-6-1-8.
Ainsi, on permute 051-025-048-116-129-090-051-064 selon la permutation numéro 5.
En permutant
051-025-048-116-129-090-051-064
selon la 5e permutation
3-2-5-4-7-6-1-8
on a donc comme résultat le 'clair 3' permuté suivant:
048-025-129-116-051-090-051-064
Ainsi, cette façon de permuter pourrait prendre le 1er caractère et le placer finalement en 1324e position.
Après avoir permuter l'ensemble du clair, on crée la clef puis on chiffre le clair via un xor entre la clef de session et le clair. Ainsi en est-il pour empêcher une attaque à clair connu.
Qu'en pense-t-on?
Raymond H.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: ctsqok$1qhj$1@biggoron.nerim.net...
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é.
Je viens de trouver une solution pour tenter d'éliminer la possibilité
d'une attaque à clair connu (donc, via un en-tête connu à cause de
l'extension du nom du fichier).
Avant de chiffrer avec un xor, je fais une permutation du clair par
groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e
caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les
10 choix disponibles de permutation pour les 8 caractères qui précèdent ce
9e caractère. Donc, le choix de permutation est imprévisible. Ensuite
seulement, on chiffre.
Donc, on additionne chacun des 8 caractères selon la valeur du rang de
chaque caractère dans la chaîne. Ceci pour aider à éviter qu'un cycle
recommence si le clair n'est composé que des caractères ascii zéro.
Exemple de clair en ascii:
050-023-045-112-124-084-045-056-056 = clair 1
+
001-002-003-004-005-006-007-008-009-... = valeur à additionner
051-025-048-116-129-090-051-064-065 =clair 2
Ensuite, on fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute du caractère 1 à 8, puis de 5 à 12, de 9 à 16, de 13
à 20, etc.
Voici les 10 choix de permutation. On change donc l'ordre des 8 caractères
à permuter (1er, 2e, 3e ,4e, 5e, 6e, 7e, 8e, 9e, 10e)
0) 8-1-7-2-6-3-5-4
Ici le 8e caractère du 'clair 2' deviendrait le 1er dans le 'clair 3'; le
1er deviendrait le 2e, le 7e deviendrait le 3e, etc.
1) 2-4-6-8-1-3-5-7
2) 1-3-5-7-2-4-6-8
3) 1-4-7-2-5-8-3-6
4) 2-1-4-3-6-5-8-7
5) 3-2-5-4-7-6-1-8
6) 4-3-2-1-8-7-6-5
7) 4-5-3-6-2-7-1-8
8) 5-4-6-3-7-2-8-1
9) 1-8-2-7-3-6-4-5
Exemple:
Le 9e caractère du 'clair 2' est 065. Le chiffre de droite de ce 9e
caractère ascii est 5. Donc, on permute avec la permutation numéro 5,
c'est-à-dire selon cet ordre: 3-2-5-4-7-6-1-8.
Ainsi, on permute 051-025-048-116-129-090-051-064 selon la permutation
numéro 5.
En permutant
051-025-048-116-129-090-051-064
selon la 5e permutation
3-2-5-4-7-6-1-8
on a donc comme résultat le 'clair 3' permuté suivant:
048-025-129-116-051-090-051-064
Ainsi, cette façon de permuter pourrait prendre le 1er caractère et le
placer finalement en 1324e position.
Après avoir permuter l'ensemble du clair, on crée la clef puis on
chiffre le clair via un xor entre la clef de session et le clair. Ainsi en
est-il pour empêcher une attaque à clair connu.
"Christophe HENRY" a écrit dans le message de news: ctsqok$1qhj$
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é.
Je viens de trouver une solution pour tenter d'éliminer la possibilité d'une attaque à clair connu (donc, via un en-tête connu à cause de l'extension du nom du fichier).
Avant de chiffrer avec un xor, je fais une permutation du clair par groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les 10 choix disponibles de permutation pour les 8 caractères qui précèdent ce 9e caractère. Donc, le choix de permutation est imprévisible. Ensuite seulement, on chiffre.
Donc, on additionne chacun des 8 caractères selon la valeur du rang de chaque caractère dans la chaîne. Ceci pour aider à éviter qu'un cycle recommence si le clair n'est composé que des caractères ascii zéro.
Exemple de clair en ascii:
050-023-045-112-124-084-045-056-056 = clair 1
+
001-002-003-004-005-006-007-008-009-... = valeur à additionner
051-025-048-116-129-090-051-064-065 =clair 2
Ensuite, on fait la permutation par groupe de 8 caractères à tous les 4 caractères. On débute du caractère 1 à 8, puis de 5 à 12, de 9 à 16, de 13 à 20, etc.
Voici les 10 choix de permutation. On change donc l'ordre des 8 caractères à permuter (1er, 2e, 3e ,4e, 5e, 6e, 7e, 8e, 9e, 10e)
0) 8-1-7-2-6-3-5-4
Ici le 8e caractère du 'clair 2' deviendrait le 1er dans le 'clair 3'; le 1er deviendrait le 2e, le 7e deviendrait le 3e, etc.
1) 2-4-6-8-1-3-5-7
2) 1-3-5-7-2-4-6-8
3) 1-4-7-2-5-8-3-6
4) 2-1-4-3-6-5-8-7
5) 3-2-5-4-7-6-1-8
6) 4-3-2-1-8-7-6-5
7) 4-5-3-6-2-7-1-8
8) 5-4-6-3-7-2-8-1
9) 1-8-2-7-3-6-4-5
Exemple:
Le 9e caractère du 'clair 2' est 065. Le chiffre de droite de ce 9e caractère ascii est 5. Donc, on permute avec la permutation numéro 5, c'est-à-dire selon cet ordre: 3-2-5-4-7-6-1-8.
Ainsi, on permute 051-025-048-116-129-090-051-064 selon la permutation numéro 5.
En permutant
051-025-048-116-129-090-051-064
selon la 5e permutation
3-2-5-4-7-6-1-8
on a donc comme résultat le 'clair 3' permuté suivant:
048-025-129-116-051-090-051-064
Ainsi, cette façon de permuter pourrait prendre le 1er caractère et le placer finalement en 1324e position.
Après avoir permuter l'ensemble du clair, on crée la clef puis on chiffre le clair via un xor entre la clef de session et le clair. Ainsi en est-il pour empêcher une attaque à clair connu.
Qu'en pense-t-on?
Raymond H.
Christophe HENRY
Je viens de trouver une solution pour tenter d'éliminer la possibilité d'une attaque à clair connu (donc, via un en-tête connu à cause de l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les 10 choix disponibles de permutation pour les 8 caractères qui précèdent ce 9e caractère. Donc, le choix de permutation est imprévisible. Ensuite seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne dépend pas d'une clé. Si tu numérote de 0 à 9 : il y a dix caractères et le dernier caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on chiffre le clair via un xor entre la clef de session et le clair. Ainsi en est-il pour empêcher une attaque à clair connu.
On mathématise un poil : M le Message clair. C le chiffré K la clé b() fonction de brouillage c() fonction de chiffrement
Le brouillage préalable se traduit par : b(M)
Le chiffrement du brouillé se traduit par : C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs. Il va donc falloir passer le brouillage qui n'est un chiffrement par substitution à clé unique. Avant on avait, en gros, une superposition de deux chiffrements à clés, maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage ne sert plus à rien puisque la fonction est disponible dans le code source. De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas censé disposer du code source du chiffrement. Pas bon.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Je viens de trouver une solution pour tenter d'éliminer la possibilité
d'une attaque à clair connu (donc, via un en-tête connu à cause de
l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par
groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e
caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les
10 choix disponibles de permutation pour les 8 caractères qui précèdent ce
9e caractère. Donc, le choix de permutation est imprévisible. Ensuite
seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on
chiffre le clair via un xor entre la clef de session et le clair. Ainsi en
est-il pour empêcher une attaque à clair connu.
On mathématise un poil :
M le Message clair.
C le chiffré
K la clé
b() fonction de brouillage
c() fonction de chiffrement
Le brouillage préalable se traduit par :
b(M)
Le chiffrement du brouillé se traduit par :
C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction
réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la
fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs. Il va donc falloir passer le
brouillage qui n'est un chiffrement par substitution à clé unique. Avant
on avait, en gros, une superposition de deux chiffrements à clés,
maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage
ne sert plus à rien puisque la fonction est disponible dans le
code source.
De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème
devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas
censé disposer du code source du chiffrement. Pas bon.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Je viens de trouver une solution pour tenter d'éliminer la possibilité d'une attaque à clair connu (donc, via un en-tête connu à cause de l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi les 10 choix disponibles de permutation pour les 8 caractères qui précèdent ce 9e caractère. Donc, le choix de permutation est imprévisible. Ensuite seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne dépend pas d'une clé. Si tu numérote de 0 à 9 : il y a dix caractères et le dernier caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on chiffre le clair via un xor entre la clef de session et le clair. Ainsi en est-il pour empêcher une attaque à clair connu.
On mathématise un poil : M le Message clair. C le chiffré K la clé b() fonction de brouillage c() fonction de chiffrement
Le brouillage préalable se traduit par : b(M)
Le chiffrement du brouillé se traduit par : C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs. Il va donc falloir passer le brouillage qui n'est un chiffrement par substitution à clé unique. Avant on avait, en gros, une superposition de deux chiffrements à clés, maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage ne sert plus à rien puisque la fonction est disponible dans le code source. De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas censé disposer du code source du chiffrement. Pas bon.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
