"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: csc16i$31i4$1@biggoron.nerim.net...
> Le Sat, 15 Jan 2005 13:42:43 -0500, Raymond H. a écrit :
>
>> Dans ce cas ce ne serait pas vraiment sur l'algo de cryptage du clair
>> qu'il faudrait se pencher mais sur l'algo de prolongement d'une clef,
>
> C'est une erreur. Je vais faire description imagée. Imagine que la clé
> en question fasse deux caractères a et b, tu la prolonges de un
> caractère au moyen de l'opération c=a+b.
> La clé est ainsi (a,b,c). Question : (a,b,c) peut-il avoir toutes les
> combinaisons possibles de a,b et c ? Il s'agit de l'une des conditions
> draconiennes imposées à l'OTP auquel ton algo est, au mieux, équivalent.
>
> La réponse est non : le nombre de combinaisons ne sera que de 256², le
> troisième élément étant dépendant des deux autres. Or, la clé doit
> remplir entièrement les possibilités de combinaisons, soit 256**3, pour
> être correcte.
>
Il est presque certain qu'avec c=a+b ça ne tiendra pas. On suppose que
la clef doit avoir un minimum de caractères: 32 bits par exemple.
k = 1-2-3-4 (clef de session initiale créée aléatoirement)
m = 5-6-7-8-9-0 (clair)
x = 0 (au départ)
k5 = (((k2 + k3) xor m1) + k4) Modulo 256
c(x+1) = (((k1 + m(x+1) xor k2) + k1) Modulo 256 [Je simplifie ici]
x = x + 1
Dans notre exemple, on conserverait toujours 4 caractères dans notre
clef de session puisqu'elle avait 4 caractères lors de son initialisation.
donc k = 1-2-3-4
donc m = 5-6-7-8-9-0
On conserve donc la clef de session finale 20-21-37-78 pour pouvoir
déchiffrer le cryptogramme 6-16-19-13-31-21
En résumé avec:
m = 5-6-7-8-9-0
k = 1-2-3-4
on produit:
k = 2-3-4-4
c = 6
k = 3-4-4-5
c = 6-16
k = 4-4-5-20
c = 6-16-19
k = 4-5-20-21
c = 6-16-19-13
k = 5-20-21-37
c = 6-16-19-13-31
k = 20-21-37-78
c = 6-16-19-13-31-21
La question est: 'Pouvons-nous trouver le clair à partir de l'algo et du
chiffré 6-16-19-13-31-21 ?
x = 0 (au départ)
k5 = (((k2 + k3) xor m1) + k4) Modulo 256
c(x+1) = (((k1 + m(x+1) xor k2) + k1) Modulo 256
x = x + 1
Ici, j'ai fait un peu vite la partie de l'algo pour le prolongement de
la clef de session; faudrait regarder la façon la plus sûre. Mais, on
pourrait faire les additions et les xor avec d'autres valeurs:
Par exemple, au lieu de faire
k5 = ((k2 + k3) xor m1) + k4
on pourrait faire (en ajoutant le modulo que je n'ai pas mis pour que ce
soit plus simple à l'oeil):
k5 =( ((k2 + m1) xor k3) + k4) Modulo 256
Bonne journée.
Raymond H.
=================
N.B.:
En transformant
c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256
c2=(((k2 + k3 + m2 + m3) xor k3) + k2) Mod 256
c3=(((k3 + k4 + m3 + k4 ) xor k4) + k3) Mod 256 (k4 remplace aussi m4)
en
c1=(((k1 + m1) xor k2) + k1) Mod 256
c2=(((k2 + m2) xor k3) + k2) Mod 256
c3=(((k3 + m3) xor k4) + k3) Mod 256 (k4 remplace aussi m4)
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?
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?
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?
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. Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition. On reste dans le domaine des substitutions. La cryptanalyse est triviale.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
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. Ce qui m'a ennuyé
(sans rendre l'algo plus fort) est le mélange du xor et de l'addition. On
reste dans le domaine des substitutions. La cryptanalyse est triviale.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
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. Ce qui m'a ennuyé (sans rendre l'algo plus fort) est le mélange du xor et de l'addition. On reste dans le domaine des substitutions. La cryptanalyse est triviale.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
