DES - problèmes avec le déchiffrement

Francois Grieu

03/05/2005 à 08:10

Dans l'article ,
"wawaye" a un problème

Je viens de tester mon programme avec une entrée et une
clé en hexa, pour le chiffrement ça marche bien.

Pour le déchiffrement, par contre, le résultat que
j'obtiens n'est pas du tout ce qu'il faut.

D'après ce que j'ai compris, l'algorithme est exactement le
même pour le chiffrement et pour le déchiffrement, la
venant du fait que les clés sont utilisées à l'inverse :
différence si les clés K1, puis K2, ... puis K16 sont
utilisées pour le chiffrement, alors pour le déchiffrement
j'utiliserai d'abord K16, puis K15, etc jusqu'à K1.

Oui. Une erreur dans les boites S ne provoque pas ce symptôme.
Le plus probable à ce stade est que

- il y a un bug dans l'inversion des sous-clés
OU
- il a été conclu que le chiffrement fonctionne sans avoir
implémenté et vérifié l'inversion finale de L et R et/ou la
permutation finale
OU
- l'exemple utilisé pour valider le chiffrement a des valeurs
non aléatoires pour le clair ou le chiffré.

Vérifier le chiffrement complet (IP/FP compris) avec
des valeurs aléatoires comme
KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC
K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C
K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF
Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274

François Grieu

wawaye

04/05/2005 à 13:53

Bonjour.

Oui. Une erreur dans les boites S ne provoque pas ce symptôme.
Le plus probable à ce stade est que

- il y a un bug dans l'inversion des sous-clés
j'ai affiché mes sous-clés, elles sont bien inversées pour le

déchiffrement

OU
- il a été conclu que le chiffrement fonctionne sans avoir
implémenté et vérifié l'inversion finale de L et R et/ou la
permutation finale
Concernant ce problème d'inversion finale de L et R : d'après tous

les schémas de fonctionnement du des que j'ai trouvé, après chaque
ronde il y a invesion de L et R, sauf après la dernière ronde. Mais
voilà ce que je lis dans un bouquin de crypto : "Notez que les parties
gauche et droite ne sont pas échangée après la dernière ronde du DES ;
c'est le bloc R16L16 qui est utilisé comme entrée pour la permutation
finale".
Ce que je comprends pas, c'est que justement si on inverse pas après la
dernière ronde, on va se retrouver avec L16 à gauche, et R16 à droite,
donc une fois regroupé ça va donner L16R16. C'est pourquoi je pense
qu'à ce niveau là il doit y avoir un problème de compréhension de ma
part, et donc d'algo

OU
- l'exemple utilisé pour valider le chiffrement a des valeurs
non aléatoires pour le clair ou le chiffré.

Vérifier le chiffrement complet (IP/FP compris) avec
des valeurs aléatoires comme
KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC
K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C
K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF
Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274

J'ai testé tout ça,
voilà ce que j'obtiens :
1) KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC :
chiffrement ok déchiffrement -> 797C0831FE21476A
2) K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C :
chiffrement ok déchiffrement -> 9AEE356715E64D46
3) K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF :
!!chiffrement -> 8E9280FDFC1222FC
4) Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274 :
chiffrement ok déchiffrement -> 4B09AF17F7358F41
Pour 1), 2) et 4), le chiffrement est bon, mais pas le déchiffrement,
j'ai précisé ce que ça me donnait quand je déchiffrais
Pour 3), le chiffrement n'est pas bon

Je précise ici ma procédure de chiffrement/déchiffrement pour 64 bits
(je mélange l'algo, le programme, et le français : je synthétise un
peu) :

[début]

permutation du bloc
permutation de la clé

récupération des moitiés gauche et droite du bloc
on a alors input_left et input_right

récupération des moitiés gauche et droite de la clé
on a alors cle_left et cle_right

generation et stockage dans un tableau des 16 sous clés
if (mode=='c') // chiffrement
{
for (int i=0;i<16;i++)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
tab_subkey est mon tableau de sous clés, et subkey_generator
une fonction qui... génère les clés ;)
}
else // déchiffrement
{
for (int i;i>=0;i--)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
}

// itération principale

for (ronde=1;ronde<17;ronde++)
{
temp_right=input_right;
bloc<-cipher(input_right,tab_subkey[ronde-1]);
// cipher est une procédure qui correspond à la fonction de
chiffrement.
temp_left<-ou_exclusif(input_left,bloc);

--------
if (ronde!)
|
{
|
input_left=temp_right; // Pour chaque
ronde il y a inversion |
input_right=temp_left; // des parties
gauche et drote |
}
|
c'est à ce niveau là je pense qu'il risque d'y avoir un problème...
else
|
{
|
input_left=temp_left; // Pour la
dernière ronde (ronde = 16) |
input_right=temp_right; // il n'y a pas
d'inversion |
}
|
}
|

|
// regroupement des parties gauche et droite du bloc
|
output<-regroupement(input_left,input_right)
|

--------

permutaiton finale

[fin]

voilà, merci encore de votre aide...

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

Bonjour.

Oui. Une erreur dans les boites S ne provoque pas ce symptôme.
Le plus probable à ce stade est que

- il y a un bug dans l'inversion des sous-clés
j'ai affiché mes sous-clés, elles sont bien inversées pour le

déchiffrement

OU
- il a été conclu que le chiffrement fonctionne sans avoir
implémenté et vérifié l'inversion finale de L et R et/ou la
permutation finale
Concernant ce problème d'inversion finale de L et R : d'après tous

les schémas de fonctionnement du des que j'ai trouvé, après chaque
ronde il y a invesion de L et R, sauf après la dernière ronde. Mais
voilà ce que je lis dans un bouquin de crypto : "Notez que les parties
gauche et droite ne sont pas échangée après la dernière ronde du DES ;
c'est le bloc R16L16 qui est utilisé comme entrée pour la permutation
finale".
Ce que je comprends pas, c'est que justement si on inverse pas après la
dernière ronde, on va se retrouver avec L16 à gauche, et R16 à droite,
donc une fois regroupé ça va donner L16R16. C'est pourquoi je pense
qu'à ce niveau là il doit y avoir un problème de compréhension de ma
part, et donc d'algo

OU
- l'exemple utilisé pour valider le chiffrement a des valeurs
non aléatoires pour le clair ou le chiffré.

Vérifier le chiffrement complet (IP/FP compris) avec
des valeurs aléatoires comme
KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC
K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C
K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF
Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274

J'ai testé tout ça,
voilà ce que j'obtiens :
1) KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC :
chiffrement ok déchiffrement -> 797C0831FE21476A
2) K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C :
chiffrement ok déchiffrement -> 9AEE356715E64D46
3) K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF :
!!chiffrement -> 8E9280FDFC1222FC
4) Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274 :
chiffrement ok déchiffrement -> 4B09AF17F7358F41
Pour 1), 2) et 4), le chiffrement est bon, mais pas le déchiffrement,
j'ai précisé ce que ça me donnait quand je déchiffrais
Pour 3), le chiffrement n'est pas bon

Je précise ici ma procédure de chiffrement/déchiffrement pour 64 bits
(je mélange l'algo, le programme, et le français : je synthétise un
peu) :

[début]

permutation du bloc
permutation de la clé

récupération des moitiés gauche et droite du bloc
on a alors input_left et input_right

récupération des moitiés gauche et droite de la clé
on a alors cle_left et cle_right

generation et stockage dans un tableau des 16 sous clés
if (mode=='c') // chiffrement
{
for (int i=0;i<16;i++)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
tab_subkey est mon tableau de sous clés, et subkey_generator
une fonction qui... génère les clés ;)
}
else // déchiffrement
{
for (int i;i>=0;i--)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
}

// itération principale

for (ronde=1;ronde<17;ronde++)
{
temp_right=input_right;
bloc<-cipher(input_right,tab_subkey[ronde-1]);
// cipher est une procédure qui correspond à la fonction de
chiffrement.
temp_left<-ou_exclusif(input_left,bloc);

--------
if (ronde!)
|
{
|
input_left=temp_right; // Pour chaque
ronde il y a inversion |
input_right=temp_left; // des parties
gauche et drote |
}
|
c'est à ce niveau là je pense qu'il risque d'y avoir un problème...
else
|
{
|
input_left=temp_left; // Pour la
dernière ronde (ronde = 16) |
input_right=temp_right; // il n'y a pas
d'inversion |
}
|
}
|

|
// regroupement des parties gauche et droite du bloc
|
output<-regroupement(input_left,input_right)
|

--------

permutaiton finale

[fin]

voilà, merci encore de votre aide...

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour.

Oui. Une erreur dans les boites S ne provoque pas ce symptôme.
Le plus probable à ce stade est que

- il y a un bug dans l'inversion des sous-clés
j'ai affiché mes sous-clés, elles sont bien inversées pour le

déchiffrement

OU
- il a été conclu que le chiffrement fonctionne sans avoir
implémenté et vérifié l'inversion finale de L et R et/ou la
permutation finale
Concernant ce problème d'inversion finale de L et R : d'après tous

les schémas de fonctionnement du des que j'ai trouvé, après chaque
ronde il y a invesion de L et R, sauf après la dernière ronde. Mais
voilà ce que je lis dans un bouquin de crypto : "Notez que les parties
gauche et droite ne sont pas échangée après la dernière ronde du DES ;
c'est le bloc R16L16 qui est utilisé comme entrée pour la permutation
finale".
Ce que je comprends pas, c'est que justement si on inverse pas après la
dernière ronde, on va se retrouver avec L16 à gauche, et R16 à droite,
donc une fois regroupé ça va donner L16R16. C'est pourquoi je pense
qu'à ce niveau là il doit y avoir un problème de compréhension de ma
part, et donc d'algo

OU
- l'exemple utilisé pour valider le chiffrement a des valeurs
non aléatoires pour le clair ou le chiffré.

Vérifier le chiffrement complet (IP/FP compris) avec
des valeurs aléatoires comme
KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC
K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C
K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF
Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274

J'ai testé tout ça,
voilà ce que j'obtiens :
1) KéB57CD0759BD31C P!5A95811C4D4549 CÙ3AE835E78AFBAC :
chiffrement ok déchiffrement -> 797C0831FE21476A
2) K374CD04F2F8CB5 PQDE9AEE5F319D6A Cp66BF87C732439C :
chiffrement ok déchiffrement -> 9AEE356715E64D46
3) K[F2231373E6F83D P+2364D442A9F742 C¼9E264CAB5265DF :
!!chiffrement -> 8E9280FDFC1222FC
4) Kô382A9EBC32FD52 P}A08C2BA5502794 C´85C755F3085274 :
chiffrement ok déchiffrement -> 4B09AF17F7358F41
Pour 1), 2) et 4), le chiffrement est bon, mais pas le déchiffrement,
j'ai précisé ce que ça me donnait quand je déchiffrais
Pour 3), le chiffrement n'est pas bon

Je précise ici ma procédure de chiffrement/déchiffrement pour 64 bits
(je mélange l'algo, le programme, et le français : je synthétise un
peu) :

[début]

permutation du bloc
permutation de la clé

récupération des moitiés gauche et droite du bloc
on a alors input_left et input_right

récupération des moitiés gauche et droite de la clé
on a alors cle_left et cle_right

generation et stockage dans un tableau des 16 sous clés
if (mode=='c') // chiffrement
{
for (int i=0;i<16;i++)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
tab_subkey est mon tableau de sous clés, et subkey_generator
une fonction qui... génère les clés ;)
}
else // déchiffrement
{
for (int i;i>=0;i--)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...)
}

// itération principale

for (ronde=1;ronde<17;ronde++)
{
temp_right=input_right;
bloc<-cipher(input_right,tab_subkey[ronde-1]);
// cipher est une procédure qui correspond à la fonction de
chiffrement.
temp_left<-ou_exclusif(input_left,bloc);

--------
if (ronde!)
|
{
|
input_left=temp_right; // Pour chaque
ronde il y a inversion |
input_right=temp_left; // des parties
gauche et drote |
}
|
c'est à ce niveau là je pense qu'il risque d'y avoir un problème...
else
|
{
|
input_left=temp_left; // Pour la
dernière ronde (ronde = 16) |
input_right=temp_right; // il n'y a pas
d'inversion |
}
|
}
|

|
// regroupement des parties gauche et droite du bloc
|
output<-regroupement(input_left,input_right)
|

--------

permutaiton finale

[fin]

voilà, merci encore de votre aide...

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

wawaye

04/05/2005 à 19:27

Autre précision : j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas des clés
intermédiaires), et là ça fonctionne : après le déchiffrement je
retrouve bien mon bloc clair initial.
Ceci m'amène à dire que le problème vient donc des clés, mais mes clés
sont correctes pour le chiffrement, et j'ai vérifié par affichage que
pour le déchiffrement, elles sont bien inversées. Il y a t il quelque
chose d'autre à faire ?
Je me retrouve un peu comme si j'étais face à un puzzle de 10 pièces
dont 9 sont bien placées, et pas la dernière :'(

Je compte sur vous pour m'aider, car je sais pas où chercher ailleurs.
Quand je cherche sur internet ou sur des bouquins, tout ce que je
trouve pour le déchiffrement, c'est : il faut inverser les clés et
utiliser le meme algorithme !!

Merci d'avance...

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

Francois Grieu

05/05/2005 à 11:13

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R16) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

Dans les articles <mn.248f7d55dadc4815.27222@wanadoo.fr>
et <mn.23417d558ffacc39.27222@wanadoo.fr>,
"wawaye" <wawaye@wanadoo.fr> dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R16) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

Vous avez filtré cet utilisateur ! Consultez son message

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R16) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

Francois Grieu

05/05/2005 à 16:32

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec une correction d'un indice]

Dans les articles <mn.248f7d55dadc4815.27222@wanadoo.fr>
et <mn.23417d558ffacc39.27222@wanadoo.fr>,
"wawaye" <wawaye@wanadoo.fr> dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec une correction d'un indice]

Vous avez filtré cet utilisateur ! Consultez son message

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S((E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S((E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S((E(R14) XOR K15))
L16 = L15 XOR P(S((E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S((E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S((E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S((E(R30) XOR K02))
L32 = L31 XOR P(S((E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec une correction d'un indice]

Francois Grieu

05/05/2005 à 16:53

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S(E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S(E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S(E(R14) XOR K15))
L16 = L15 XOR P(S(E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S(E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S(E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S(E(R30) XOR K02))
L32 = L31 XOR P(S(E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec des corrections]

Dans les articles <mn.248f7d55dadc4815.27222@wanadoo.fr>
et <mn.23417d558ffacc39.27222@wanadoo.fr>,
"wawaye" <wawaye@wanadoo.fr> dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S(E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S(E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S(E(R14) XOR K15))
L16 = L15 XOR P(S(E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S(E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S(E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S(E(R30) XOR K02))
L32 = L31 XOR P(S(E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec des corrections]

Vous avez filtré cet utilisateur ! Consultez son message

Dans les articles
et ,
"wawaye" dit

après chaque ronde il y a inversion de L et R, sauf
après la dernière ronde.

Oui (je considérais que après chaque ronde, on échange L et R,
et que l'on les rééchange encore une fois à la fin avant la
permutation finale; c'est équivalent).

tout ce que je rouve pour le déchiffrement, c'est: il faut
inverser les clés et utiliser le meme algorithme !!

Oui, c'est en effet suffisant. Mis à part les permutations
initiales et finales, et l'extraction des sous-clés Kj,
un chiffrement DES du clair L00#R00 se résume à
L01 = R00 R01 = L00 XOR P(S(E(R00) XOR K01))
L02 = R01 R02 = L01 XOR P(S(E(R01) XOR K02))
..
L15 = R14 R15 = L14 XOR P(S(E(R14) XOR K15))
L16 = L15 XOR P(S(E(R15) XOR K16)) R16 = R15

si on poursuit par le déchiffrement, on réalise
L17 = R16 R17 = L16 XOR P(S(E(R16) XOR K16))
L18 = R17 R18 = L17 XOR P(S(E(R17) XOR K15))
..
L31 = R30 R31 = L30 XOR P(S(E(R30) XOR K02))
L32 = L31 XOR P(S(E(R31) XOR K01)) R32 = R31

Il est facile de démontrer que
L17 = R15 R17 = L15
L18 = R14 R18 = L14
..
L31 = R01 R31 = L01
L32 = L00 R32 = R00

donc que le déchiffrement "marche" seulement en traitant
les sous-clés Kj dans l'ordre inverse, sans AUCUN autre
changement.

Pour 3), le chiffrement n'est pas bon

Vous avez 3 exemples sur 4 où votre chiffrement DES de
données et clés aléatoires est correct (mon exemple est bon).
C'est hautement indicateur d'erreur(s) dans quelque(s)
valeur(s) des boites S, indépendemment du problème du
déchiffrement.

j'ai affiché mes sous-clés, elles sont bien inversées pour
le déchiffrement

Ca ne serait peut-être pas inutile de refaire cette vérif car
il est aussi rapporté:

j'ai essayé de chiffrer et déchiffrer avec une clé
initiale qui ne contient que des zéros (et donc ce sera le cas
des clés intermédiaires), et là ça fonctionne : après le
déchiffrement je retrouve bien mon bloc clair initial.

ce qui est hautement indicateur que les sous-clés sont mal
inversées pendant le déchiffrement.

Quand tout semblera fonctionner, il sera utile de
réaliser le test de Rivest:
http://theory.lcs.mit.edu/~rivest/destest.txt

François Grieu

[reposté avec des corrections]

wawaye

07/05/2005 à 14:22

Bonjour,
ça y est, mon problème est résolu !

effectivement il y avait bien un problème avec mes clés, je ne
comprends pas que je l'aie pas vue lors de mes premières vérifications.

pour stocker et générer mes clés, j'utilise :

generation et stockage dans un tableau des 16 sous clés
if (mode=='c') // chiffrement
{
for (int i=0;i<16;i++)
tab_subkey[i]<-subkey_generator(cle_left,cle_right,...i
...)
}
else // déchiffrement
{
for (int i;i>=0;i--)

tab_subkey[i]<-subkey_generator(cle_left,cle_right,...i...)

----
}

je rappelle que tab_subkey est mon tableau de sous clés, et
subkey_generator une fonction qui. génère les clés . Cette fonction
prend en paramètre le numéro de la ronde, or pour le déchiffrement je
pars de la dernière ronde (pour stocker les clés), et donc mon numéro
de ronde était faux. il ne fallait pas mettre i, mais 15-i. A celà
s'ajoutais des erreurs de saisie dans les tables-S...

Donc voilà, maintenant ça marche. Encore merci pour votre aide
précieuse

--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

DES - problèmes avec le déchiffrement

7 réponses

Veuillez sélectionner un problème