Simple algo: 3e étape - attaque à clair ou chiffré connu

Salut !

Le cassage n'est pas dépendant de la longueur de la clé, trouver une
clé est l'affaire de trente secondes. Par contre, si on veut toutes
les clés, le temps de sortie grandit énormement.

Effectivement... mais une seule me suffira ;-)

Jack : tu peux m'expliquer en gros comment tu as fait ? Pour ma part, j'ai
trouvé des solutions par une série de recherches exhaustives sur la
combinaison des opérations xor et addition...

Oui. Voir ci-dessous.

Voici un challenge, histoire de...
Le clair : [254;178;245]
Le chiffré : [ 80; 91;223]
La première clé est : [ 0 80 10 78 ]

oui ! J'ai pareil, ça rassure...

Quelques intermédiaires : [ 10 214 148 174 ]
[ 22 122 122 174 ]
La dernière est : [ 254 254 254 174 ]

J'ai pareil. L'avant-dernière est [254 254 252 174]

Le temps de calcul est de 1 heure 9 minutes 22 secondes !

Le temps de calcul est presque nul (instantané)
Le temps d'affichage des valeurs est de 22s (bah ouais j'ai une console
de 80 lignes...) :D. Avec 1 ligne de console ça ne prend plus que 2s :p

Pour donner le temps de *calcul*, j'ai recompilé sans l'affichage,
because 22s ça me paraissait long.

Il y 62'560 (soixante-deux mille et des poussières) clés équivalentes.
La première clé est trouvée instantanément. Pour les avoir toutes, ça
a été bien plus long. Plus il y a de clé possibles, plus c'est
long. S'il n'y en avait qu'une seule, cela prendrait 30 secondes :-)

Effectivement, pour avoir *toutes* les clés j'ai parcouru 0.007% de
l'ensemble des clés avec le challenge à Raymond, et 0.4% de l'espace des
clés avec le tien.

Et y'a une astuce pour gagner énormément de temps...

Je prend un tableau de valeurs k = [0 0 0 0]
C'est lui qui va représenter une clé valide. On commence avec des 0
(zéro) partout.
Soit i un index qui pointe sur la (i+1)ème valeur de k. On commence avec
i = 1 (deuxième élément).

donc k = [0 0 0 0]
et i = 1----^

à partir de l'octet du clair m[i-1] et de k[i] et k[i-1] je peux
calculer le chiffré c[i-1].
Et bien, je le fais ! Si c'est pas correct (ne correspond pas au bon
chiffré) alors j'incrémente k[i].
- Si k[i] != 0 alors, je recommence
- Si k[i] == 0 alors, j'ai fais le tour des 256 valeurs.
- - Si i != 1 alors je décrémente i et incrémente par la suite k[i]
- - Si i == 1 alors je remets à zéro touts les coeffs sauf k[0] qui sera
incrémenté.
- - - Si k[0] == 0 alors j'ai terminé de tester tout l'espace des clés
et j'ai rien trouvé... bizarre !
Par contre, si le résultat du calcul est correct, j'ai un bon début de
clé, et :
- Si i ne pointe pas sur le dernier élément de k, j'incrémente i
- Si i pointe sur le dernier élément de k, j'ai trouvé une clé valide et
j'ai gagné : dodo.

Rem : au dernier élément de k, là le calcul est légèrement différent, et
on teste donc différemment. a voir à l'implémentation.

En gros, on construit tout doucement l'arbre de l'ensemble des clés,
mais branche par branche. On parcourt les branches prioritairement en
profondeur, et on élague dès qu'elle ne répond plus à une solution
possible de clé.
Ca permet d'élaguer très rapidement, et d'aller très vite vers la
première clé valide.

On pourrait encore optimiser grâce à certaines propriétés remarquables
de l'algo de R.H. mais c'est inutile avec une clé de 32 bits.

Bon, ça a l'air compliqué comme ça mais ça marche bien, et quelque soit
la longueur de la clé. Si la clé est courte (32bits) par exemple, y'a
une solution plus facile à implémenter et viable (ici, ton challenge) :

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char *argv[])
{
int k1,k2,k3,k4;
int compteur;
int tests;
compteur=0;
tests=0;

for (k1=0;k1<255;k1++)
{
for (k2=0;k2<255;k2++,tests++)
{
if ((((k1+k2+254+178) ^ k2)+k1)%256 == 80)
{
for (k3=0;k3<255;k3++,tests++)
{
if ((((k2+k3+178+245) ^ k3)+k2)%256 == 91)
{
for (k4=0;k4<255;k4++,tests++)
{
if ((((k3+k4+245+k4) ^ k4)+k3)%256 == 223)
{
compteur++;
printf("%i : K={%i,%i,%i,%i}n",compteur,k1,k2,k3,k4);
}
}
}
}
}
}
}
printf ("%i testsn",tests);
return 0;
}

Bon, évidemment faut réécrire le programme à chaque changement de clé,
et c'est surtout embêtant quand la clé change de longueur ou est très
longue. Perso, je préfère l'arbre à branche unique... (ouais c'est
bizarre comme nom, mais comme on élague tout ce qui n'est pas bon, et
qu'on construit l'arbre au fur et à mesure, et ben y'a qu'une branche à
tout instant... :p)

Bon amusement !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/

Bon, faut forcément que je me gourasse quand je file du code...
Alors je corrige.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

L'include de <math.h> est inutile ici. Hop ! On le vire.

int main(int argc, char *argv[])
{
int k1,k2,k3,k4;
int compteur;
int tests;
compteur=0;
tests=0;

for (k1=0;k1<255;k1++)

Bêtise de haute voltige, la condition d'arrêt mauvaise...
on corrige par :

for (k1=0;k1<256;k1++)
{
for (k2=0;k2<256;k2++,tests++)
{
if ((((k1+k2+254+178) ^ k2)+k1)%256 == 80)
{
for (k3=0;k3<256;k3++,tests++)
{
if ((((k2+k3+178+245) ^ k3)+k2)%256 == 91)
{
for (k4=0;k4<256;k4++,tests++)
{
if ((((k3+k4+245+k4) ^ k4)+k3)%256 == 223)
...
Le reste semble potable.

Désolé. Si vous avez testé le code et obtenu des résultats incorrects,
c'est de ma faute. Bah quoi... ça arrive...

Sinon j'ai profité d'un peu de temps pour tester une clé de 64bits.
avec M = [ 23 116 69 90 195 208 17]
et C = [ 141 191 165 39 157 239 39]

Je trouve les 626688 clés valides en une fraction de seconde, une fois
de plus.
On a doublé la longueur de la clé... et je ne parcours que 0.02
milliardièmes de l'espace de clés. On peut pas dire que ça l'allongement
de la clé ne complique énormément la chose.

Tiens, une clé marrante, la 113488 : K={1,2,3,4,5,6,7,8}

@Tchao !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/

Hello à tous,

Je suis très content de voir le boulot de Jack. Non, sérieux ! Il fait
en 30 centièmes de secondes ce que mon prog a fait en 2h. Et comme je ne
suis pas rancunier, je file aussi le source du mien.
Attention : c'est de la qualité, là...

Voici un challenge, histoire de...
Le clair : [254;178;245]
Le chiffré : [ 80; 91;223]
La première clé est : [ 0 80 10 78 ]

oui ! J'ai pareil, ça rassure...

Dans ce monde si cruel on se sent seul...

Le temps de calcul est de 1 heure 9 minutes 22 secondes !

Le temps de calcul est presque nul (instantané)
Le temps d'affichage des valeurs est de 22s (bah ouais j'ai une console
de 80 lignes...) :D. Avec 1 ligne de console ça ne prend plus que 2s :p

Ah ben oui, là. Je suis battu à plate coutures. C'est marrant de voir
les démarches différentes que nous avons suivies.

Pour donner le temps de *calcul*, j'ai recompilé sans l'affichage,
because 22s ça me paraissait long.

$ time ./jack
real 0m2.827s
user 0m0.218s
sys 0m0.071s

$ time ./jack >/dev/null
real 0m0.329s
user 0m0.200s
sys 0m0.002s

...
En gros, on construit tout doucement l'arbre de l'ensemble des clés,
mais branche par branche. On parcourt les branches prioritairement en
profondeur, et on élague dès qu'elle ne répond plus à une solution
possible de clé.
Ca permet d'élaguer très rapidement, et d'aller très vite vers la
première clé valide.

<sous_entendu>
Pas mieux. Un bon informaticien est avant tout un faignant. Et vu nos
temps de calculs respectifs...
</sous_entendu>

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char *argv[])
{
...

Mmmh ! Du code bien crade qui tourne du tonnerre. Tu as été un peu dur
quand même. En ajoutant des variables tu aurais pu généraliser pour
n'importe quel clair et n'importe quel chiffré.

Bon, évidemment faut réécrire le programme à chaque changement de clé,
et c'est surtout embêtant quand la clé change de longueur ou est très
longue. Perso, je préfère l'arbre à branche unique... (ouais c'est
bizarre comme nom, mais comme on élague tout ce qui n'est pas bon, et
qu'on construit l'arbre au fur et à mesure, et ben y'a qu'une branche à
tout instant... :p)

Les autres amateurs de ce genre d'arbre peuvent s'inscrire sur la _liste_ ;-)


De mon côté, j'ai adopté le même principe d'élagage, sauf que j'ai
inversé la fonction. Du coup, ça marchera quelque soit la longueur des
données.

== Le principe =
Ca peut se faire rapidement avec des matrices dans le cas général, mais
là on va atterir un peu, pour le pique-nique.

Le clair étant connu, le calcul de c1,c2 et c3 peut se voir sous cette
forme :
c1 = f(k1,k2)
c2 = g(k2,k3)
c3 = h(k3,k4)

Le gros problème c'est d'inverser les fonctions f, g, h qui ne sont pas
caractéristiques du chiffrement lorsqu'elle sont prises isolément. En
plus, l'inverse débouche sur un ensemble de valeurs possibles. Il faut
donc les tester.

c1 = f(k1,k2) aboutit à un couple (k1,k2) candidat. C'est-à-dire qu'une
clé vérifie toujours cette égalité. Mais on n'est pas sûr qu'il y
aura un k3 et k4 qui correspond. D'où :

c2 = g(k2,k3) = gg(k3) revient à tester les 256 valeurs car k2 est connu.
c3 = h(k3,k4) = hh(k4) se résoud tout aussi facilement.

Voilà pour le principe, et cela rejoint ce qu'à fait Jack.

Pour inverser la fonction, je réécris les lignes :

k2 ^ (c1-k1) = k2 + (m1+m2+k1)
=======> k2 = DELTA(c1-k1,1,m1+m2+k1)

k3 ^ (c2-k2) = k3 + (m2+m3+k2)
=======> k3 = DELTA(c2-k2,1,m2+m3+k2)

k4 ^ (c3-k3) = 2*k4+(m3+k3)
=======> k4 = DELTA(c3-k3,2,m3+k3)

Et voilà :-)

Le problème, c'est que la fonction DELTA (inverseuse du XOR-addition)
renvoi un ensemble (petit) de valeurs possibles qu'il faut tester, ce qui
est l'équivalent des boucles de Jack.

Je me ramène quand même avec les matrices :
Le chiffrement est défini par l'application linéaire suivante :

C = (Mk*M+Mm*M)^Ma*K + Mb*K

C le chiffré et M le clair sont des vecteurs à 4 dimensions dont la
quatrième composante est à zéro car la clé est plus longue que le
clair. K est un vecteur à 4 dimensions.

Mk, Mm, Ma, Mb sont des matrices décrivant les paramètres de
l'algorithme.

On a ainsi :
(Ma*K)^(C-Mb*K)=Mk*K+Mm*M

On effectue un changement de repère, avec matrices de passage et tout le
toutim :
J^(C-Mb*Ma_1*J) = Mk*Ma_1*J+Mm*M avec J=Ma*K

Ainsi :
JÞLTA(C-Mb*Ma_1, Mk*Ma_1, Mm*M)

Au final :
K=Ma_1*DELTA(C-Mb*Ma_1, Mk*Ma_1, Mm*M)

En passant les détails de corps, d'anneau, le produit de deux matrices
est une matrice. Donc, en désignant toutes les matrices par un Mx :

K=M1*DELTA(C-M2, M3, M4)


Reste à voir cette fonction DELTA...

Soit l'équation en x : a^x = b*x+c. L'espace de x est confiné dans
[0..255] et l'addition est modulaire. A défaut de trouver un inverse
propre, on fait une boucle sur toutes les valeurs possibles de x afin que
l'égalité soit préservée.
Muni de cette fonction inverse, qui délivre un ensemble de x convenants,
on peut inverser tout le simple algo.


Voici le programme en scilab. Son but est ainsi de réaliser la fonction
inverse du simple algo plutôt que de passer en force brute. Ainsi, il
n'est (sauf erreur) pas sensible à la taille de la clé.

Il est plus long à lire, plus long à écrire, plus long à exécuter :-]

======================================================================= function [MODULO]=mod(_nombre,_modulo)
// Fait le modulo aves les négatifs aussi
// modulo(-5,10) devrait donner 5 mais il reste à -5
// NOTE : modulo 0 (zero) ne modifie pas le nombre
MODULO = modulo( _modulo + modulo(_nombre,_modulo), _modulo )
endfunction

// XOR sur jusqu'à 32 bits. Entiers de 8 ou 16 marchent aussi.
function [X]=xor(A,B); X=~uint32(A) & uint32(B) | uint32(A) & ~uint32(B);
endfunction

function [D]Þlta(_a, _b, _c)
resultats=[]
_a=mod(_a,256)
_b=mod(_b,256)
_c=mod(_c,256)
for x=0:255
if xor(x,_a)==mod(_b*x+_c, 256)
resultats=[resultats;x]
end
end
D=resultats
endfunction

function [C]=sax(_M,_K) // Chiffrement avec le xor et modulo en plus.
_M=[_M;0]
temp = mod(xor(Mm*_M+Mk*_K,Ma*_K)+Mb*_K,256)
C = temp(1:3)
endfunction

function [M]=sax_1(_C, _K) // Déchiffrement
_C=[_C;uint32(0)]
temp=mod(inv(Mm)*(xor(_C-Mb*_K,Ma*_K)-Mk*_K),256)
M=temp(1:3)
endfunction

function sax_casse(_M,_C) // Trouve la clé
// Principe :
// La fonction delta fournit les antécédents pour la relation
// avec le xor et l'addition.
// Pour chaque octet probable, on le fixe.
// On répète de même pour les autres valeurs.

_Corig = _C
_C=[_C;0] // Le chiffré est mis à 4 dimension
resultat=[]
compte=0
kk1=[0:255]' // On suppose bons tous les k1 possibles
for i1=1:size(kk1,'r')
K(1)=kk1(i1)
printf("k1=%dn", K(1))
kk2Þlta(_C(1)-K(1),1,_M(1)+_M(2)+K(1))
for i2=1:size(kk2,'r') // On parcours les k2 candidats
K(2)=kk2(i2)
kk3Þlta(_C(2)-K(2),1,_M(2)+_M(3)+K(2))
for i3=1:size(kk3,'r') // On a donc déjà k1, k2 puis k3
K(3)=kk3(i3)
kk4Þlta(_C(3)-K(3),2,_M(3)+K(3))
for i4=1:size(kk4,'r') // k4 est tombé, on sabre !
K(4)=kk4(i4)
dernierK = K
compte=compte+1
end //i4
end //i3
end //i2
end //i1
printf("%4d clés et la dernière est ", compte) ; printVecteur(dernierK)
printf("%4d clés trouvéesn", compte) ;
endfunction

M=[254;178;245];
K=[78;78;78;78];
C=[80;91;223];

sax_casse(M,C)
=======================================================================

Si vous lisez ça, c'est que vous avez un peu lu le code. Bravo :-o S'il
est dur à lire, c'est parce qu'il a été dur à écrire.

Amitiés,

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A

...
Désolé. Si vous avez testé le code et obtenu des résultats
incorrects, c'est de ma faute. Bah quoi... ça arrive...

Les valeurs étaient bonnes pour la simple raison qu'il n'y a pas de clés
comportant un 255. Intéressant, non ?

Sinon j'ai profité d'un peu de temps pour tester une clé de 64bits.
avec M = [ 23 116 69 90 195 208 17] et C = [ 141 191 165 39 157
239 39]
Je trouve les 626688 clés valides en une fraction de seconde, une fois
de plus.
On a doublé la longueur de la clé... et je ne parcours que 0.02
milliardièmes de l'espace de clés. On peut pas dire que ça
l'allongement de la clé ne complique énormément la chose.

Puisque je te dis que la taille n'a pas d'importance :-p

Et la phrase désormais mythique : au suivant !

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A

Je t'ai déjà dit Raymond, et tout le monde ici te l'a déjà dit ou te le
dira
: tes posts sont du verbiage, du texte creux, dont pas 10% du volume
contient de l'information. 40% sont des redites, des totologismes, des
périphrases. Les 50% restants sont du bruit, du vent, de la non
information.
Si tu fais un effort de rigueur intellectuelle, je suis certain que tu
peux
supprimer les 50% de bruit (par ex. en ne parlant pas de musique ni de
mouvement perpétuel sur un forum où tout le monde s'en tape). Reste les
40%
à éliminer par un bon formalisme, c'est à dire par le choix d'un outil
technique approprié à ton besoin, et clairement, le français de monsieur
tout le monde n'est pas l'outil technique approprié à la présentation (et
à
l'analyse) d'un algorithme.

...

Cela fait-il de moi un incompétent si je ne peux donner tous
les

noms de vos calculs et si j'utilise une méthode plus simple à la portée
du
plus grand nombre (même si je ne me souviens pas de tous les noms donnés
à
mes parties de calculs ou d'algèbres que j'ai employé)?

En un seul mot : Oui.

Dans ce cas relisez bien, surtout le début du fil à l'étape 1 du 'Simple
algo', car je suis celui qui a pu le mieux expliquer son fonctionnement de
chiffrage et déchiffrage dans un langage simple pour tout le monde. Et de
plus, lorsque j'ai amené un calcul algorithmique, je l'ai amené en détail
pour être compris par tout le monde. Je me plaçais plus au niveau de la
majorité. Voici deux exemples de ce que j'ai amené et voyez si ce n'était
pas clair (à moins que votre niveau ne vous permette pas de comprendre
ceci!):


--------->>>1 er:
51+523
52+535
53+k1=?

Donc,
249-(51+52)6 donc 249-1036 donc k16-k2
281-(52+53)6 donc 281-1056 donc k26-k3
206-(53+k1)=k3+k1 donc k3 6-(53+k1)-k1

k3 6-(53+k1)-k1
k3 6-(53+(146-k2))-(146-k2)
k3 6-(53+(146-(176-k3)))-(146-(176-k3))
k3 6-(53+(146-176+k3))-(146-176+k3)
k3 6-(53+146-176+k3)-146+176-k3
k3 6-53-146+176-k3-146+176-k3
k3+k3+k3 6-53-146+176-146+176
3k33+30+30
3k3!3
k3!3/3
k3q

Donc k3q

k26-k3
k26-71
k25

Donc k2= 105

k16-k2
k16-105
k1A

Donc k1A

Ainsi, on a la clef 41-105-71


---------<<<>>>2e:

Clé en ascii 49 50 51 (k1, k2, k3) 3
Mot en ascii 51 52 53 (m1,m2,m3) = 345
Chiffré en ascii 152 155 153 (c1,c2,c3) = ici les caractères ne sont pas
imprimables.

J'aligne pour mieux voir:
49 50 51 = clef
51 52 53 = texte clair
152 155 153 = chiffré

On crypte ainsi:
49+51+522
50+52+535
51+53+49(qui prend la place du caractère 'm4' qui n'existe pas)3

On a donc fait:
k1 + m1 + m2 = c1 = 152
k2 + m2 + m3 = c2 = 155
k3 + m3 + k1(qui prend la place du caractère 'm4' qui n'existe pas) = c3 153

Maintenant on a le chiffré 152 155 153 que l'on veut déchiffrer.
Pour déchiffrer, on fait donc l'opération inverse. On débute donc par
prendre le dernier caractère utilisé de la clef, c'est à dire 49 (donc k1,
puisqu'il prenait la place du caractère 'm4' qui n'existe pas au dernier
calcul dans le cryptage) et on le soustrait du caractère chiffré 153 (donc,
k1à soustraire de c3 , c'est-à-dire c3-k1).

On décrypte donc ainsi:
- Si, pour chiffrer, on a pris 51+53+493 on fait donc maintenant
153-49-51S pour déchiffrer.

Donc on a pris le chiffré 153 (qui était connue) et on soustrait le
caractère 49 ('k1' qui est connue et qui remplaçait 'm4' qui n'existait
pas), donc 153-49 ;
on continue en soustrayant le caractère normal de la clef (51 = k3 qui est
connue), donc 153-49-51 ;
et on arrive à la réponse 53 (m3) qui auparavant était caché. On a donc
trouvé un caractère en clair et cela seulement à partir de la clef et du
chiffré.

Maintenant qu'on a trouvé ce caractère 53 du texte en clair, on peut
l'utiliser pour trouver l'autre caractère du texte en clair.

On continue:
- Si on a pris 50+52+535 on fait donc maintenant 155-53-50R

Donc on a pris le chiffré 155 (qui était connue) et on soustrait le
caractère 53 ('m3' qu'on vient de décrypter), donc 155-53 ;

on continue en soustrayant le caractère normal de la clef (50 = k2 qui est
connue), donc 155-53-50 ;
et on arrive à la réponse 52 (m2) qui auparavant était caché. On a donc
trouvé le 2e caractère en clair à l'aide du chiffré, de la clef et du
caractère précédemment déchiffré.

Maintenant qu'on a trouvé ce 2e caractère 52 du texte en clair, on peut
l'utiliser pour trouver l'autre caractère du texte en clair qui reste à
trouver.

On continue:
- Si on a pris 49+51+522 on fait donc maintenant 152-52-49Q

Donc on a pris le chiffré 152 (qui était connue) et on soustrait le
caractère 52 ('m2' qu'on vient de décrypter), donc 152-52 ;

on continue en soustrayant le caractère normal de la clef (49 = k1 qui est
connue), donc 152-52-49 ;
et on arrive à la réponse 51 (m1) qui auparavant était caché. On a donc
trouvé le 1er caractère en clair à l'aide du chiffré, de la clef et du
caractère précédemment déchiffré.

Donc, on a trouvé le texte en clair 51 52 53 seulement à partir de la
clef 49 50 51 et du chiffré 152 155 153.
Il reste donc à transformer les nombres ascii 51 52 53 en caractères
normaux, c'est à dire 345.
---------<<<


Et si je dis quelque chose qui n'est pas clair pour vous, alors essayez
d'avoir une vue d'ensemble ou poser des questions si je ne me suis pas bien
expliqué. Vous direz que ce n'est que des chiffres ici. Dans, le 1er
exemple en algèbre 'oui', car les chiffres valent mille mots. Alors, si
vous ne comprenez pas les mots basez vous sur les chiffres quand cela le
demande. Je vous fais rappeler que ces deux exemples sont du concret au
moins. Et en plus les gens peuvent vérifier simplement si j'ai fait une
erreur ou non, et ceux qui ne comprenaient pas peuvent assez facilement
comprendre maintenant car c'est à la porté de tous.



Si vous utilisez le mot 'hémorragie' et que moi je ne connaît pas ce mot
mais que j'utilise le mot 'saignement', cela fait-il de moi un incompétent
de la langue française? Si vous dites ne pas me comprendre avec ce mot
'saignement' alors c'est vous qui a un problème car il aurait fallu
comprendre ce mot pour comprendre l'autre mot; aussi, avec ce mot je me met
au niveau de tout le monde. Si je ne vous méprise pas lorsque vous utilisez
le mot 'hémorragie' et qu'on suppose que je ne le comprenne pas, alors
pourquoi me mépriseriez-vous si moi j'utilise le mot 'saignement' que tout
le monde connaît?

De plus, votre intervention est futile, désagréable et vaine. Rien pour
encourager.


...

De
ton côté, la *lecture* est tellement laborieuse qu'elle en est rebutante
(sûrement pour masquer le fait qu'il n'y a rien à *comprendre* ?) et il y
a
donc rien à espérer de tes lecteurs (sauf le courageux assidu sus-nommé et
ses quelques corrélégionnaires).

...

Mais on sait que ce n'est pas du SPAM selon
la

définition général (une fois ou deux ou à peu près, et dans un but
différent

car j'e suis en plus sur un site traitant de ce sujet).

Une fois ou deux ou à peu près, la marge d'erreur est de l'ordre de 200%,
bonjour la rigueur.
...

Un flatteur sachant flatter ne doit pas forcément s'attendre à être flatté
en retour.

Avec tout le dénigrement qui précède, ce n'est pas de vous que
l'encouragement vient ici. Faudrait réfléchir à votre notion de bruit, de
verbiage, de vent, de non information, etc.

...

Ca ne prouve rien du tout. Pour moi aussi c'est une véritable torture
mentale lorsque je cherche à *comprendre* les idées que peut présenter un
Christophe Henry,

Vous dites le mot 'AUSSI', comme si j'avais dit que c'était une torture
mentale pour moi de comprendre Christophe Henry. Je vous fais remarquer que
je respecte son vocabulaire et sa façon d'amener ses calculs. C'est du
contraire ici qu'il est question: de ceux qui parle contre mon vocabulaire.
Ce n'est pas moi qui se plains, c'est vous.

Et si c'est une véritable torture mentale de comprendre Christophe
Henry, alors pourquoi lorsqu'il est question de me comprendre ce n'est plus
pareil?


...

Oui bien sûr. D'ailleurs, c'est bien connu, les logiciels commerciaux
n'existeraient pas sans les bénévoles qui aident les développeurs.

Pas d'accord. Faut pas généraliser.
r.h.

"Mister Jack" <news@mjcie.net> a écrit dans le message de news:
41e665e1$0$10269$626a14ce@news.free.fr...

Salut !

"Mister Jack" <news@mjcie.net> a écrit dans le message de news:

J'ose espérer que l'algo est réversible.

Bonjour,
Pourquoi? N'est-ce pas mieux qu'il soit non inversible?

Je voulais dire qu'à partir d'une clé valide et du chiffré, il soit
possible de revenir au clair... ;-)

D'accord.

Je voudrais m'avancer un peu à l'étape 4 (la création et prolongation
de la clef de session). Lorsque j'aurai assez de temps je veux vous faire
ça :-)



Une idée. Je ne sais pas ce que vous en pensez. Au début, la clef de
session initiale est créée, mais c'est la clef de session finale que
l'utilisateur doit se souvenir pour décrypter, en sorte qu'on ne crypte
pas la clef de session finale pour l'enregistrer.

Si j'ai bien suivi, votre clé de session fait la longueur du message + 1
octet... ça ne risque pas de poser un problème là ?

Ça serait seulement les derniers caractères de la clef de session que
l'utilisateur conserverait en mémoire. La même longueur que la clef de
session initiale (par exemple 64 ou 128). Puisque le déchiffrage débuterait
avec ces caractères seulement, puis au fur et à mesure du déchiffrage les
caractères manquant du début de la clef de session seraient générés
graduellement.

Sinon, puis-je poser une question qui a été un gros problème pour le
chiffrement jusque dans les années 70 ? Oui ? Merci.
:-)

Donc : comment résoudre le problème du passage de clé au destinataire ? Si
je veux vous envoyer un message avec Allcrypter, je fais comment ? Pour
l'instant, à part vous rencontrer en personne pour vous donner la clé, je
ne vois pas.
Et Si celle-ci devient à usage unique, autant vous donner le message en
mains propres.

Ca serait le même problème que de faire connaître la phrase de passe
d'un logiciel de chiffrage/déchiffrage, à l'exception que la clef devrait
être remise à toutes les fois qu'on chiffre un fichier. C'est
l'inconvénient, mais le bon côté est que c'est plus sûr dans le sens
qu'aucune phrase de passe serait intégré dans le chiffré. C'est une idée
juste comme ça, mais je préfère l'autre façon qui intègre le code
d'identification généré par la phrase de passe plutôt que la clef de session
finale, en sorte qu'on puisse utiliser toujours la même clef si on le
désire.

Disons qu'après quelques centaines de calculs, environ 95% des clés
possibles sont déjà définitivement éliminées.

Pas vraiment. Regardez au bas de ce message-ci.

Bah si je vous le dis... je vois bien que mon programmes raye
définitivement de la liste 95% des clés possibles...

D'accord, puisque votre code diffère du mien en VB qui essaie toutes les
possibilités de clefs.

Et pour casser votre algo, rien ne sert d'avoir l'ensemble des clés
possibles. Une seule suffit.

Mais 4 milliards moins les 640 ne fait presque aucune différence.

Ce que je veux vous dire, c'est que pour une clé de 1Kbit par exemple, il
faudra un temps très faible pour trouver une clé valide. Ici avec 32bits
c'est quasi-instantané.
Et avec une clé valide on peut déchiffrer le message sans difficulté
majeure.

Mais est-ce que votre code test seulement 640 clefs? Ou plus? Je n'ai
pas bien compris comment le calcul vous dirait à l'avance le nombre de
possibilité de clefs valides. Car mon code me le dit juste en dernier quand
il a testé les 4 milliards de possibilités.

N.B.: J'ai créé un programme et j'ai testé toutes les 4 milliards de
combinaisons possibles (précisément 4294967296). Voici les 640 clefs
possibles pour le clair 008-012-021 et le chiffré 032-051-062:

Ca ressemble à ce que mon programme a déterminé. La différence c'est que
votre méthode nécessite sans optimisation environ 2min de calcul sur un
Athlon 2Ghz, et que la mienne en ne testant que quelques clés bien
choisies donne le résultat quasi-instantanément. Une clé plus longue sera
déterminée rapidement.
Si vous voulez, passez-moi vos tests 64bits et 128bits sur mon mail et je
vous renverrai les résultats. Ca ira + vite chez moi.

Ça m'intéresse. Voici les données:
Avec une clef de 64 bits:
Clair 100-100-100-100-100-100-100
Chiffré : 216-216-216-216-216-216-120

Avec une clef de 128 bits:
Clair 100-100-100-100-100-100-100-100-100-100-100-100-100-100-100
Chiffré : 216-216-216-216-216-216-216-216-216-216-216-216-216-216-120

Amicalement,
--
Cordialement :-)

r.h.

"Mister Jack" <news@mjcie.net> a écrit dans le message de news:
41e66721$0$10269$626a14ce@news.free.fr...

Salut !

Si vous voulez, passez-moi vos tests 64bits et 128bits sur mon mail et je
vous renverrai les résultats. Ca ira + vite chez moi.

D'ailleurs en 64 bits, faudrait 15000 ans avec une méthode brute non
optimisée pour arriver au bout. Alors en VB je vous dis pas...
Bon courage ! :D

Je ne prends pas de risque alors car le temps passe trop vite :-))

--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/

"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: cs5pj2$a7j$1@biggoron.nerim.net...

J'ose espérer que l'algo est réversible.
Bonjour,

Pourquoi? N'est-ce pas mieux qu'il soit non inversible?

On va dire que tu pensais qu'il ne doit pas être inversible si on ne
dispose pas de la clé :-o Parce que s'il l'est AVEC la clé, ca va être
coton pour déchiffrer ;-)

Effectivement :-)

Une idée.
...
En sorte que c'est cette clef de session finale que
l'utilisateur doit écrire comme phrase de passe pour déchiffrer.

La clé de session va finir par être aussi longue que le clair, non ? Je
pensais que la phrase de passe devait être courte pour permettre à
l'utilisateur de bien la retenir.

Je ne sais pas encore la façon que je vais adopter. En effet la clef de
session serait aussi longue que le clair si on la conserverait en entier,
mais ce n'est pas le cas. Car ce serait seulement les derniers caractères
de la clef de session qui serait retenue en mémoire, puisque lors du
déchiffrage, les premiers caractères de cette clef seraient restaurés par
calcul au fur et à mesure du déchiffrement, puisque c'est l'opération
inverse de celle qui a été opérée à partir de la clef de session initiale.

Ainsi, si on le voulait, on aurait aucune phrase de passe à taper lors
d'un chiffrage mais seulement lors du déchiffrage car dans ce cas ce serait
l'algo qui fournirait les derniers caractères de la clef de session (clef
finale). Cette clef de session finale serait créée à partir de la clef de
session initiale choisie au hasard par le logiciel. Je pense qu'on pourrait
ainsi avoir un système indéchiffrable en autant que le calcul effectué pour
le prolongement graduelle de la clef de session initiale (prolongement via
la clef de session et le clair) est vraiment imprévisible si on tente un
calcul quelconque pour inverser cette clef de session finale.

Dans ces conditions, le système serait donc sûr vu qu'une seule clef
serait générée au hasard lors de chaque chiffrage. Mais le désavantage
serait de communiquer une clef de session finale pour chaque déchiffrage.


Mais dans l'autre façon de faire, la phrase de passe existerait
seulement pour que le système refuse le déchiffrage si ce n'est pas la bonne
phrase de passe qui est tapée. Cette phrase de passe crypterait également
la clef de session finale pour l'ajouter au chiffrement pour être
enregistrée dans le fichier.

L'avantage est que si l'utilisateur se trompe de clef lors du
déchiffrage, alors il ne chiffrerait pas le chiffré une 2e fois par dessus
par erreur en rendant le chiffré différent du chiffré original.

J'ai pensé aussi, qu'avant de crypter la clef de session finale et le
code d'identification (phrase de passe modifiée) je fais une permutation des
caractères de la clef de session finale (déjà cryptée). Ceci afin de
refuser la comparaison de la clef de session cryptée d'avec celle qui n'est
pas cryptée (en supposant qu'une personne aurait trouvé cette clef de
session finale via le clair et le chiffré comme vous l'avez déjà mentionné).

Exemple:

La phrase de passe: machin

Le code d'identification de la phrase de passe: COUCOU

La clef de session finale: XYZ

Par la phrase de passe on crypte donc la clef de session finale et le
code d'identification. Ensuite, on fait une permutation de tous ces
caractères chiffrés (clef de session finale cryptée et code d'identification
crypté). On permute selon l'ordre indiqué par chaque caractère de la phrase
de passe non cryptée.

Par exemple: (supposons que la clef de session finale cryptée est xyz et
que le code d'identification crypté est bonbon)

Les caractères ascii de la phrase de passe claire sont m9 , a— ,
c™ , h4 , i= 105 , n0

On prends ce chiffré xyzbonbon et on le permute selon m9 , a— ,
c™ , h4 , i= 105 , n0 . On déplace vers la droite le caractère x
109 fois, le caractère y de 97 fois, le z de 99 fois, le b de104 fois, le o
de 105, le n de 110, le b de 109, le o de 97 et le n de 99 fois. Je ne l'ai
pas essayé mais supposons que ça donnerait onzbbnxyo . Ensuite on crypte
une 2e fois : on crypte donc onzbbnxyo . On pourrait répéter ces opérations
2, 5 ou 10 fois.



Le but serait d'empêcher de trouver la phrase de passe par le moyen de
la clef de session décryptée (en supposant qu'une personne l'aurait
décryptée via le chiffré et le clair), puisque la clef de session cryptée,
permutée puis cryptée de nouveau (par la phrase de passe) ne correspondrait
plus à la clef de session décrypté (via le clair et le chiffré); on ne
saurait pas quels sont les bons caractères de la clef de session cryptés,
permutés et cryptés (par la phrase de passe).

J'ai fait un programme et il vient tout juste de terminer d'analyser
les 4 milliards de combinaisons possibles. Il a trouvé 640 clefs
possibles.

Pareil.

Combien de temps prend-il pour faire l'analyse pour trouver les clefs
possibles de 32 bits dans le même exemple auparavant donnée ?

De plus, une clé plus longue que le clair ne solidifie pas l'algo et,
dans le cas présent, affaiblit le chiffrement.

Je ne vois pas comment elle pourrait affaiblir le chiffrement puisque
c'est seulement les x premiers caractères (de la même longueur que le clair)
qui seraient utilisés.

Bonne journée.
Raymond H.

"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de
news:y6CFd.32448$b64.976221@news20.bellglobal.com...

Pas de réponse sur le fond ??? C'est dommage...

<snip>

Dans ce cas relisez bien, surtout le début du fil à l'étape 1 du
'Simple

algo', car je suis celui qui a pu le mieux expliquer son fonctionnement de
chiffrage et déchiffrage dans un langage simple pour tout le monde. Et de
plus, lorsque j'ai amené un calcul algorithmique, je l'ai amené en détail
pour être compris par tout le monde. Je me plaçais plus au niveau de la
majorité. Voici deux exemples de ce que j'ai amené et voyez si ce n'était
pas clair (à moins que votre niveau ne vous permette pas de comprendre
ceci!):

<snip de 3 page de chiffres, désolé mais je n'ai plus de papier listing sous
la main. Le copié-collé est une abomination et on devrait l'interdire pour
Raymond>

Je répète parce que manifestement tu n'as pas lu mon message : tu n'es pas
lisible parce que tu n'es pas concis / rigoureux / clair. Ce n'est pas en
recopiant bêtement 3 pages déjà postées ici que tu seras plus concis, c'est
plutôt le contraire. Alors maintenant de 2 choses l'unes : soit tu comprends
ce que tu fais, et tes 3 pages tiennent sur 3 à 5 lignes, et je me ferait un
plaisir de lire ces lignes et même de chercher à les comprendre. Soit il y a
tant d'entropie dans ta tête que tu es incapable d'expliquer proprement
quoique ce soit, soit tu montres que tu es capable d'expliquer proprement et
les lecteurs fainéants comme moi seront enfin motivés pour chercher à
comprendre.

Et si je dis quelque chose qui n'est pas clair pour vous, alors
essayez

d'avoir une vue d'ensemble ou poser des questions si je ne me suis pas
bien

expliqué. Vous direz que ce n'est que des chiffres ici. Dans, le 1er
exemple en algèbre 'oui', car les chiffres valent mille mots. Alors, si
vous ne comprenez pas les mots basez vous sur les chiffres quand cela le
demande. Je vous fais rappeler que ces deux exemples sont du concret au
moins. Et en plus les gens peuvent vérifier simplement si j'ai fait une
erreur ou non, et ceux qui ne comprenaient pas peuvent assez facilement
comprendre maintenant car c'est à la porté de tous.

Non, les chiffres ne valent pas mille mots. Réfléchis un peu, si tu ne sais
construire un algorithme que par son application numérique, ce n'est plus un
algorithme, c'est une table de valeurs de sortie en fonction des valeurs
d'entrée. En un mot, c'est du stockage, pas de l'algorithmique.

Si vous utilisez le mot 'hémorragie' et que moi je ne connaît pas ce
mot

mais que j'utilise le mot 'saignement', cela fait-il de moi un incompétent
de la langue française? Si vous dites ne pas me comprendre avec ce mot
'saignement' alors c'est vous qui a un problème car il aurait fallu
comprendre ce mot pour comprendre l'autre mot; aussi, avec ce mot je me
met

au niveau de tout le monde. Si je ne vous méprise pas lorsque vous
utilisez

le mot 'hémorragie' et qu'on suppose que je ne le comprenne pas, alors
pourquoi me mépriseriez-vous si moi j'utilise le mot 'saignement' que tout
le monde connaît?

Je répépépépéte pour Raymond qui est manifestement un incompétent de
mauvaise fois en plus. OUI, le fait de ne pas connaître un mot de
vocabulaire montre ton incompétence en vocabulaire. Il n'y a pas de honte,
il n'y a pas mort d'homme, on s'en remet, on peut vivre sans, on peut
progresser, mais en l'occurence on est incompétent. Cela ne devient une tare
que quand on persiste à vouloir le rester. Pour en revenir à ton application
numérique (pardon, ton exemple sanguignolant), n'importe quel élève de CP
qui n'aurait pas ta mauvaise fois se rend compte simplement en ouvrant un
dictionnaire que deux mots considérés comme synonymes par le langage courant
ne sont que très rarement absolument interchangeables, pour la bonne et
simple raison qu'ils n'ont jamais rigoureusement la même définition. Au delà
du langage parlé, choisir l'un plutôt que l'autre introduit souvent une
nuance ou une précision technique qui a son importance dans un langage écrit
rigoureux. Or, que je sache, nous sommes ici dans le domaine de l'écrit, il
n'y a pas lieu de mépriser ceux qui ne savent pas écrire, mais il faut à
tout le moins les encourager à progresser fissa-fissa.

De plus, votre intervention est futile, désagréable et vaine. Rien
pour

encourager.

Désagréable, je sais, c'est fait pour. Tant que c'est pas méprisant ça va,
c'est que je suis du bon côté de la ligne jaune de mon karma. Vaine, je
sais, mais c'est plutôt par la volonté du lecteur que par la mienne,
n'est-ce pas ? Toute intervention est bonne à prendre, pour qui accepte la
critique. Futile, tant mieux, j'espère que d'autres auront trouvé comme toi
(et comme moi) un peu de distraction à me lire, après tout, on n'est pas là
pour ne faire que dans le sérieux... Et rien pour encourager, absolument, je
le revendique. Je ne vais tout de même pas t'encourager à continuer à écrire
comme tu parles, à croire que tu as inventé la pierre philosophale un matin
en te rasant, et à raconter qu'on a la preuve du mouvement perpétuel.

<snip>

Avec tout le dénigrement qui précède, ce n'est pas de vous que
l'encouragement vient ici. Faudrait réfléchir à votre notion de bruit, de
verbiage, de vent, de non information, etc.

J'y ai réfléchi (oh, pas longtemps, je te l'accorde, je préfère tapoter
fiévreusement un texte futile que de réfléchir trop longtemps à sa
pertinence, question de mauvais esprit). Mon étiquette personnelle et la
bienséance me répugne à poster ici ce genre de messages qui in-fine ne
concernent que toi et que manifestement tu ne souhaites pas chercher à
comprendre. C'est promis, dès qu'il y a un sujet pertinent qui passe à ma
portée j'arrête de troller pour me distraire...

Ca ne prouve rien du tout. Pour moi aussi c'est une véritable torture
mentale lorsque je cherche à *comprendre* les idées que peut présenter
un

Christophe Henry,

Vous dites le mot 'AUSSI', comme si j'avais dit que c'était une
torture

mentale pour moi de comprendre Christophe Henry. Je vous fais remarquer
que

je respecte son vocabulaire et sa façon d'amener ses calculs. C'est du
contraire ici qu'il est question: de ceux qui parle contre mon
vocabulaire.

Ce n'est pas moi qui se plains, c'est vous.

Qui a dit que je ne respectait pas son vocabulaire ou son travail ??? Je
disais juste que pour le suivre il fallait que je m'accroche, parce que mes
neurones sont plutôt en sommeil côté calcul matriciel et espaces vectoriels.
Alors, oui, pour moi c'est une torture mentale, de réveiller ces neurones,
comme ce serait une torture physique de me faire monter l'Alpe d'Huez en
vélo. C'est une image Raymond, une figure de style, ouh ouh faut pas tout
prendre au pied de la lettre Raymond...

Et si c'est une véritable torture mentale de comprendre Christophe
Henry, alors pourquoi lorsqu'il est question de me comprendre ce n'est
plus

pareil?

Parce que tu compares l'Alpe d'Huez à un terril de vieux pays minier. Tant
qu'à souffrir, autant que ce soit pour un beau paysage.

Tu comprends Raymond, c'est encore une image ?

Oui bien sûr. D'ailleurs, c'est bien connu, les logiciels commerciaux
n'existeraient pas sans les bénévoles qui aident les développeurs.

Pas d'accord. Faut pas généraliser.

Des exemples ??? Pour une fois, ça manque de chiffre.


Bonne journée sur le Parc.
--
JD

Je ne sais pas encore la façon que je vais adopter. En effet la clef de
session serait aussi longue que le clair si on la conserverait en entier,
mais ce n'est pas le cas. Car ce serait seulement les derniers caractères
...

J'attend les spécifications précises.

Je pense qu'il n'est pas utile de se fourvoyer dans laïus en Français
dont il ne serait pas possible d'avoir à la fois un descriptif
compréhensible par le plus grand nombre et un descriptif précis et sans
ambiguité. On se rapproche de la cryptographie quantique mixée avec les
théories de Shannon, là :-o

...
Mais dans l'autre façon de faire, la phrase de passe existerait
seulement pour que le système refuse le déchiffrage si ce n'est pas la
bonne phrase de passe qui est tapée.

Ce n'est pas le système qui va refuser. C'est l'interface graphique de
ton logiciel. Ce n'est pas un concept de cryptologie. Sépare les deux.

L'avantage est que si l'utilisateur se trompe de clef lors du
déchiffrage, alors il ne chiffrerait pas le chiffré une 2e fois par
dessus par erreur en rendant le chiffré différent du chiffré
original.

C'est de la programmation d'interface utilisateur, pas de crypto. Si tu
mets des scories dans l'algorithme, tu risques de rendre plus difficile
son étude (par moi, en tout cas) sans le rendre plus fort.
Sépare-donc la programmation de l'algorithme.

L'algo reçoit en entrée le Message, une ou plusieurs Klés (selon tes
implémentations) et en sort le Chiffré, dont la seule définition
devrait être qu'il sort de l'algo, ni plus ni moins.

J'ai pensé aussi, qu'avant de crypter la clef de session finale et
le
code d'identification (phrase de passe modifiée) je fais une
permutation des caractères de la clef de session finale (déjà
...
c™ , h4 , i= 105 , n0 . On déplace vers la droite le
caractère x 109 fois, le caractère y de 97 fois, le z de 99 fois, le b
de104 fois, le o de 105, le n de 110, le b de 109, le o de 97 et le n de
99 fois. Je ne l'ai pas essayé mais supposons que ça donnerait
onzbbnxyo . Ensuite on crypte une 2e fois : on crypte donc onzbbnxyo .
On pourrait répéter ces opérations 2, 5 ou 10 fois.

Substitution poly-alphabétique. Chiffre de Vernam.
C1 = M + 99
C2 = C1 + 7
C3 = C2 - 8
C4 = 51154 + C3

Compliqué, non ? Comment retrouver M avec C4 ?
Simple : M = C4 - 51252

Le clair comprend bien plus qu'un seul caractère ? Les matrices aussi.

Combien de temps prend-il pour faire l'analyse pour trouver les clefs
possibles de 32 bits dans le même exemple auparavant donnée ?

2 minutes pour toutes les énumérer. Une clé valide est trouvée tout de
suite. Mon programme est plutôt une preuve de concept mettant en échec
l'utilisation combinée du xor et de l'addition. Celui de Jack devrait
être pris comme référence, vu qu'il est très simple à lire.

Le mien, donné dans ce fil, résistera bien plus à de futures
modifications de l'algorithme.

De plus, une clé plus longue que le clair ne solidifie pas l'algo et,
dans le cas présent, affaiblit le chiffrement.

Je ne vois pas comment elle pourrait affaiblir le chiffrement
puisque
c'est seulement les x premiers caractères (de la même longueur que le
clair) qui seraient utilisés.

Je travaille sur les spécifications publiées. L'algorithme 'simple algo
avec xor' servant à chiffrer sur 3 octets utilise le quatrième octet de
la clé, qui en fait d'ailleurs 4.

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A