Simple algo...

Christophe HENRY wrote:

De ce fait, j'avais construit un (petit) dictionnaire contenant tous
les 65536 Cf. Je ne connaissait pas le Ci (celui de mes frêres ;-)
mais
j'avais des mots de passes équivalents qui donnaient le même Cf.
Le frangin : "SonMotDePasse". f("SonMotDePasse") = 0x457a
Moi-même : "unAutreTruc", f("unAutreTruc") = 0x457a

Nos deux mots de passe étaient équivalents.

Héhé, j'ai fait de même, il doit y avoir 7-8 ans, pour craquer les mots de
passe de certains BIOS AWARD. Un chtit dico de hashés et zou. Le plus dur
fut de trouver combien de bits étaient réinjectés dans la fonction. Si je
retouve ça et si ça interesse quelqu'un, je le mettrai sur mon site tiens.

--
AMcD®

http://arnold.mcdonald.free.fr/

"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
41cd858b$0$21446$636a15ce@news.free.fr...

Raymond H. wrote:

Bonjour,

disons qu'on vous demanderait plus encore. On vous demanderait un
texte en clair et son texte chiffré, puis un autre texte chiffré avec
la même clef. Et on vous demanderais aussi l'algorithme que vous
utilisez.

Tu sais Raymond, c'est comme cela que ça marche la cryptographie... Une
technique n'est vraiment efficace que si tout le monde peut vérifier,
tester, éprouver dans tous les sens. Si avec l'algorithme sous les yeux,
et donc la possibilité de l'étudier, de implémenter, tu ne parviens pas à
caser le chiffré, déjà, c'est bien plus fiable comme base de départ :-).

Tout à fait d'accord :-) C'est pourquoi je veux présenter ici les

calculs de l'algo de la version bêta 3 (disons) lorsque je l'aurai complété
ou jugé prête pour être éprouvé. Comme vous dites, c'est la meilleure chose
à faire.
a+
Raymond H.

Bonjour,

je viens de relire mon explication précédente et je me suis aperçu que
j'ai fait une petite erreur par inattention. On doit remplacer les phrases
"(qui prend la place du caractère suivant 'c4' qui n'existe pas)=" par "(qui
prend la place du caractère 'm4' qui n'existe pas)=".



Plus bas, lors du décryptage, ça équivaudrait dans un certain sens à un
XOR 'non dépendant' quand on fait 153-49-51S pour déchiffrer, puisque
153-49-513+(-100)S. Mais cela n'est vrai que pour la première
opération puisque 'm4' n'existe pas lors de la première opération et que son
remplaçant k1 fait partie de la clef au même titre que 'k3' qui est aussi
nécessaire pour cette première opération de décryptage.

Mais pour les opérations de décryptage qui suivent, cela correspondrait
à un XOR 'dépendant' (si on peut vraiment le comparer à un XOR en le faisant
de cette façon) car pour chaque c(x) déchiffré, le calcul lui-même dépend du
précédent m(x) trouvé. Donc, une différence quand on voudrait déchiffrer
c1ou c2 de façon isolé car ils ne peuvent pas être déchiffrés de façon isolé
puisqu'ils dépendent de chaque calcul précédent qui doit être fait pour
trouver leur m(x) dont ils ont besoin à chaque fois (à l'exception du 1er
calcul dans le décryptage) pour être déchiffrés en plus de la clef.



Je reproduis donc mon explication ici pour une suite plus facile dans sa
lecture.


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.

Je pense que cette fois-ci c'est plus clair. Qu'en pensez-vous ? :-)

Bonne journée
Raymond H.

Bonjour,

je viens de relire mon explication précédente et je me suis aperçu que
j'ai fait une petite erreur par inattention. On doit remplacer les phrases
"(qui prend la place du caractère suivant 'c4' qui n'existe pas)=" par "(qui
prend la place du caractère 'm4' qui n'existe pas)=".

L'algorithme reste totalement défini par :

k1 + m1 + m2 = c1
k2 + m2 + m3 = c2
k3 + m3 + k1 = c3

La totalité de mes écrits restent donc d'actualité :
<cqhimi$gac$1@biggoron.nerim.net>

Plus bas, lors du décryptage, ça équivaudrait dans un certain sens à un
XOR 'non dépendant' quand on fait 153-49-51S pour déchiffrer, puisque
153-49-513+(-100)S. Mais cela n'est vrai que pour la première
opération puisque 'm4' n'existe pas lors de la première opération et que son
remplaçant k1 fait partie de la clef au même titre que 'k3' qui est aussi
nécessaire pour cette première opération de décryptage.

Une vue différente sur les opérations mécaniques ne change rien aux
problèmes de l'algorithme. En fait, ta méthode peut très largement
être optimisée avec du calcul matriciel. Tout sera calculé en un seul
coup :

C = Mm x M + Mk x K

C = le chiffré (la totalité du chiffré, quelque soit la longueur)
M = le "mot", donc le message en clair
K = la klé :-)

Mm et Mk sont des matrices de passage qui traduisent de manière
exhaustive ton algorithme. Elles possèdent les valeurs disponibles dans
mon autre post.

Dans le cas d'un xor, Mm et Mk sont unitaires. Autrement dit, elle ne font
rien et on a :

C = M + K

De plus, compliquer le chiffrement avec de multiples occurrences et
coefficients attachés au parties de M et de K ne ferait que modifier les
valeurs des matrices Mm et Mk, en aucun cas cela complique l'algorithme.

Cela est du au fait que le passage du clair vers le chiffré est dû à
des combinaisons linéaires, des additions en ajoutant un coefficient
devant chaque membre additionné.

...car ils ne peuvent pas être déchiffrés de façon isolé
puisqu'ils dépendent de chaque calcul précédent qui doit être fait
pour trouver leur m(x) dont ils ont besoin à chaque fois (à
l'exception du 1er calcul dans le décryptage) pour être déchiffrés
en plus de la clef.

Dans la version itérative, tu as raison. Mais pas dans l'absolu :
Soit le système d'équations linéaires :
x1 + x2 = 10
2(x1) - 5(x2) = -24

On calcule d'abord x2 en fonction de x1 : y2 = 10 - x1
On passe ensuite la valeur de x dans la deuxième ligne :
2(x1) - 5(10-x1) = -24
Equation triviale à resoudre, qui devient : x1 = 3.
De là, on calcule x2 : x2 = 10 - 3 = 7

L'algèbre linéaire dit que : "A.X = Y". X est le vecteur (x1,x2) et Y
est le vecteur (10,-24). X est la matrice traduisant le système
d'équation linéaires.

[ [1 1] ] ( (x1) ( (y1)
* =
[2 -5] ] (x2) ) (y2) )


Le système s'inverse en "X = ( A^(-1) ) x Y".
Le "A puissance moins 1" est la façon de noter la matrice inverse, celle
qui trouve le X avec les Y.

On aurait alors :
[ [0.7142857 0.1428571] ] ( (y1) ( (x1)
* =
[0.2857143 -0.1428571] ] (y2) ) (x2) )


x1, x2, ainsi que tous les autres s'il y en avait, sont calculés en un
coup. Pas x1 puis x2, non. Tous d'un coup.

J'arrête ici les frais ;-) Mais tout cela est très puissant et peut se
faire avec des vecteurs aussi grands qu'on veut.

Je reproduis donc mon explication ici pour une suite plus facile
dans sa lecture.

Tu as changé de lunettes mais la carte routière est toujours la même.

Je pense que cette fois-ci c'est plus clair. Qu'en pensez-vous ?

Il s'agit (toujours) de la résolution d'un système d'équation.
Mon avis reste inchangé.

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)

Bonjour,

j'ai lu attentivement vos explications dans la façon de calculer avec
des matrices... c'est très intéressant.

Ici, plus bas, je colle quelques-unes de vos citations antérieures pour nous
rappeler certaines de vos conclusions sur le simple algo. Ceci afin de
conclure l'étape de l'algo direct de cryptage/décryptage relié SEULEMENT au
chiffré immédiat.

Autrement dit, j'aimerais, avant de continuer à traiter au niveau
extérieur de l'algo, savoir votre conclusion, à savoir:

sans tenir compte des attaques externes (brutes ou à claire: donc sans tenir
compte des essais itératifs de clefs différentes ou des comparaisons du
chiffré avec le clair et/ou avec la clef), est-il possible, à votre avis,
tout en connaissant l'algo

(celle que j'ai défini dans ce petit exemple:

k1 + m1 + m2 = c1
k2 + m2 + m3 = c2
k3 + m3 + k1 = c3

)

mais en ne connaissant pas la clef mais en connaissant uniquement le
chiffré, est-il possible dis-je, de faire une inversion de calcul de cet
algo ou un calcul quelconque différent à partir de cet algo en sorte qu'une
personne puisse trouver la clef qui a servie à chiffrer le texte en clair?
C'est-à-dire, peut-on trouver la clef à partir seulement de l'algo connu et
du chiffré connue (mais en ne tenant pas compte d'une attaque à clair, donc
en ne faisant pas de comparaisons de textes clairs d'avec les chiffrés, et
autres attaques externes) ? Dans mon petit exemple, je crois que 'non'; je
crois qu'il est impossible de trouver la clef à partir de n'importe lequel
des calculs imaginables en s'en tenant qu'au simple algo que j'ai présenté
ici (plus haut) et au chiffré.



Je m'explique: pour débuter le décryptage, il faut connaître au moins
deux caractères de la clef (k1 et k2 dans notre exemple), et en supposant
qu'on se sert de la table des 256 caractères ascii, on aurait jusqu'à une
possibilité de 65536 essais (donc sur 16 bits) pour trouver c'est deux
caractères par comparaisons via des calculs. Et même là, en réalité, les
essais doivent être faits sur plus de 2 caractères et ainsi monteraient
jusqu'à un maximum de 16777216 possibilité (donc sur 24 bits) avec les
combinaisons avec 3 caractères, puisque ce 3e caractère qui est le dernier
caractère chiffré dont il faut tenir compte (1er caractère=k1, 2e = k3 et
3eÃ). Donc, cet ensemble de comparaisons pour ne trouver qu'un seul
caractère nécessaire pour trouver celui du chiffré (le 1er à trouver)
donnerait une possibilité maximale de 16777216 essais (et ce caractère
trouvé on ne peut pas être sûr que c'est le bon puisqu'il faut continuer le
calcul); il faut ensuite continuer pour trouver le prochain caractère
chiffré qui à son tour donnerait une possibilité maximale de 4294967296
essais (donc sur 24 bits), puisque même après avoir fait les 16777216 essais
pour le 1er caractère on ne saurait jamais si c'est le bon caractère puisque
ça pourrait être n'importe lequel, et cela vaut aussi pour le 2e caractères
qui ne dirait jamais si c'est le bon non plus à cause du trop grand nombre
de mots possibles qui peuvent renfermer ces deux lettres. Et il y a un trop
grand nombre de possibilité (pour deux caractères) pour les fichiers binaire
comme les jpeg, bmp, avi, etc. .



Tous ceci pour dire qu'il serait plus facile d'essayer toutes les
combinaisons possibles en essayant de taper toutes les clefs possibles à
l'endroit prévu pour écrire la clef dans ce logiciel éventuel (en supposant
qu'on ferait un logiciel avec cet algo).



Donc, je tiens à préciser ici, que c'est seulement en rapport avec
l'algo et le chiffrer et non en faisant des comparaisons de plusieurs texte
en clair et plusieurs chiffrés ou autres attaques externes à l'algo
lui-même. Je pose cette question afin de passer à l'étape suivante: à
savoir si l'algo peut être cassé par une attaque à clair (je voudrais qu'on
ne réponde pas à cette question-ci tout de suite mais seulement après avoir
conclue avec la question principale nommé ci avant, car ensuite je voudrais
ajouter un calcul pour créer une sous chaîne à partir de la clef pour servir
d'intermédiaire entre la clef et le texte clair à chiffrer, et cela pour
savoir si l'algo pourra résister à une attaque à clair; mais je voudrais
qu'on poursuivre cette question seulement après avoir répondu à la question
principal ci haut. Si la réponse est que vous croyez qu'on peut, avec
seulement l'algo et le chiffrer, trouver la clef alors je demanderais une
preuve avec calcul simple à l'appui à partir du même petit exemple donné
plus haut.



En procédant par étapes cela sera moins mélangeant pour tout le monde et
on saura où on s'en va, et plusieurs en seront instruit du même coup par les
réponses d'autres personnes. Donc, une étape à la fois donnerait plus de
certitude dans notre cheminement.



Voici quelques-unes des réponses que vous avez donnez antérieurement pour
nous faire rappeler certaines de vos conclusions sur le simple algo de ce
message.

On trouve que le problème est de trouver M tel que M = C - f(Ci)

En fait, le problème ne revient pas à trouver Ci, mais revient à
trouver f(Ci). Connaître la clé initiale ne sert pas à grand chose. Il
s'agit d'un cas de rejeu, et on retombe sur ce problème de réutilisation
de la clé.

Donc, un problème externe à l'algo et non de faire le traitement qui se
limite uniquement via une inversion de l'algo sans faire de comparaison
entre le chiffré et le clair.
...

Le chiffrement (sauf le xor) a pour but concrêt de protéger contre le
temps.

Donc, avec le xor vous dites qu'il est possible d'empêcher au moins
certaines inversions. Et vous dites que le simple algo que j'ai présenté a
une façon de calcul de l'ordre du xor.
...

J'en conclue que la robustesse théorique de l'algorithme est au mieux du
même ordre qu'un XOR.
... Utiliser des matrices
unitaires n'affaiblirait pas le procédé :

...

Les attaques possibles sont celles prééxistant pour le XOR. Autant faire
du XOR.

...

Je pense que l'algorithme est (potentiellement) aussi fort qu'un XOR dont
il prend aussi les faiblesses : la réutilisation des clés (ou mots de
passe) va grandement faciliter les déchiffrements.

Donc, vous dites que la faiblesse serait dans la réutilisation de la
clef, autrement dit d'une attaque à clair (donc, d'une comparaison du
chiffré avec le texte en clair qu'il faut avoir connu).

J'attends donc les réponses de quiconque avec calculs à l'appui selon
l'exemple ci-dessous si la réponse est négative.
Voici la question de nouveau:
Est-il possible de faire une inversion de calcul de cet algo ou un
calcul quelconque à partir de cet algo (ou à partir seulement du chiffré
sans le clair) en sorte qu'une personne puisse trouver la clef (123) qui a
servie à chiffrer le texte clair (345) ? C'est-à-dire, peut-on trouver la
clef à partir seulement de l'algo connu et du chiffré (c1,c2,c3) connue
(mais en ne tenant pas compte d'une attaque à clair, donc en ne faisant pas
de comparaisons de textes clairs avec les chiffrés, et autres attaques
externes comme une attaque brute) ?

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)

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 suivant 'c4' qui n'existe pas)3

k1 + m1 + m2 = c1
k2 + m2 + m3 = c2
k3 + m3 + k1 = c3

Je remercie donc les personnes qui on participées et qui participent à
ce fils de discussion qui dégage certaines choses instructives
Raymond H.

[...] mais en ne connaissant pas la clef mais en connaissant uniquement
le chiffré, est-il possible dis-je, de faire une inversion de calcul de
cet algo ou un calcul quelconque différent à partir de cet algo en sorte
qu'une personne puisse trouver la clef qui a servie à chiffrer le texte
en clair?

Etant donne' l'algorithme de chiffrement utilise', il est
trivial d'implementer une attaque a partir du chiffre' seul
(sans connaitre le clair ni faire de recherche exhaustive sur
la clef), a condition que la clef soit significativement plus
courte que le message a chiffrer.
Si le clair ayant fourni le chiffre' est suffisemment "varie'"
(i.e. si on y trouve les sequences de deux octets consecutifs
suivantes: [0x00, 0x00] et [0xFF, 0xFF]), il est possible de
retrouver la clef. Bien entendu si l'intervalle de caracteres
utilise' pour le clair est plus reduit (exemple: caracteres
ASCII imprimables), l'attaque devient encore plus rapide
(i.e. il suffit d'un chiffre' de longueur moindre).

La technique consiste a majorer et minorer les valeurs de
k[i] (on se contentera du minorant si vous utilisez des
modulo):

i = 0;
char min_k[3] = [0,0,0];
char max_k[3] = [0,0,0];
Pour( i = 0; i<nb_elements(c); i++){
si(c[i] < max_k[i%3]){
max_k[i%3] = c[i];
} //finsi
si(c[i] > min_k[i%3]){
min_k[i%3] = c[i];
} //finsi
} //fin tant que


max_k[0]-Q2;
max_k[1]-Q2;

Pour i = 0 ou i = 1 :
--> min_k[i] <= k[i] <= max_k[i]

On en deduit k[2].

[...]
Donc, un problème externe à l'algo et non de faire le traitement qui se
limite uniquement via une inversion de l'algo sans faire de comparaison
entre le chiffré et le clair.

Il faut que vous realisiez que les attaques a clair connu revelent une
faiblesse de l'algorithme utilise', et pas un "probleme externe a
l'algo" : en pratique, dans de nombreux cas, une partie du clair peut
etre devinee (cas typique : parties invariantes des en-tetes de fichier).
Les attaques a clair connu permettent alors de retrouver la partie
inconnue du fichier a partir d'une partie connue. Il va falloir vous y
faire : un algo vulnerable a une attaque a clair connu est un algo
pourri (et je ne sais pas d'ou vous tenez ce terme abracadabrant
d'"attaque externe").

Enfin, comme l'ecrivait Christophe, il importe peu que l'on puisse
remonter
a la clef d'origine si ce n'est pas elle qui sert au chiffrement. Par
exemple, dans le processus suivant :

Clef1 <--- Utilisateur

Clef2 <---[MD5]--- Clef1

Clef2
|
Chiffre'<--[Chiffrement]-- Clair

L'introduction d'une etape irreversible (le calcul d'une empreinte MD5)
ne perturbe en rien la cryptanalyse : en pratique, c'est Clef2 que l'on
recherche et qui sert a chiffrer. Pire, l'utilisation d'une empreinte
MD5 est susceptible de reduire la robustesse de l'algorithme en
introduisant des collisions (deux Clef1 peuvent donner la meme Clef2)
et en reduisant l'espace de recherche.

Je remercie donc les personnes qui on participées et qui participent à
ce fils de discussion qui dégage certaines choses instructives

Pourtant, vous semblez ignorer superbement le principal enseignement qui
se degage de cette discussion : un algorithme de chiffrement robuste ne
se concoit pas en quelques jours. D'autant moins quand le concepteur
est inexperimente'. Jusqu'ici, tout contribue a montrer que votre
algo ne vaut pas tripette et vous persistez a vouloir l'utiliser
plutot que de vous fier a des algorithmes eprouves. C'est dommage.

--
Tweakie


--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net

Bonjour à tous,

J'en rajoute une couche, et juste au premier niveau du fil histoire de
bien marquer la nouvelle année :

Le chiffrement était défini par :
c1 = m1 + m2 + + k1
c2 = m2 + m3 + + k2
c3 = m3 + k1 + k3

en prenant C comme étant le chiffré.
en prenant M comme étant le mot (le clair).
en prenant K comme étant la clé (la Klé).
La taille des données est la même que celle de la clé, 3 nombres.

Le déchiffrement est défini par :
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3
m2 = c2 - c3 + k1 - k2 + k3
m3 = c3 - k1 - k3

Le processus est valable pour toute taille de la clé et du clair, à
supposer qu'ils ont la même taille. Le modulo a été négligé, mais ça
n'apporterait rien de plus.

Bon début d'année :-)

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

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

Bonjour à tous,

J'en rajoute une couche, et juste au premier niveau du fil histoire de
bien marquer la nouvelle année :

Le chiffrement était défini par :
c1 = m1 + m2 + + k1
c2 = m2 + m3 + + k2
c3 = m3 + k1 + k3

en prenant C comme étant le chiffré.
en prenant M comme étant le mot (le clair).
en prenant K comme étant la clé (la Klé).
La taille des données est la même que celle de la clé, 3 nombres.

Le déchiffrement est défini par :
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3

Bonjour,
ici que signifie le '-2' ? Car en algèbre ça se définirait ainsi:
m1 = (c1 - c2 + c3 ) - (2*k1) + ( k2 - k3)
et de cette façon le résultat ne correspond pas.

m2 = c2 - c3 + k1 - k2 + k3
m3 = c3 - k1 - k3

Le processus est valable pour toute taille de la clé et du clair, à
supposer qu'ils ont la même taille. Le modulo a été négligé, mais ça
n'apporterait rien de plus.

Bon début d'année :-)

Merci, et bonne année à vous aussi :-)

Raymond H.

"Tweakie" <NO_eikaewt_SPAM@hotmail.com> a écrit dans le message de news:
33apq9F3t2p1aU1@individual.net...

[...] mais en ne connaissant pas la clef mais en connaissant uniquement
le chiffré, est-il possible dis-je, de faire une inversion de calcul de
cet algo ou un calcul quelconque différent à partir de cet algo en sorte
qu'une personne puisse trouver la clef qui a servie à chiffrer le texte
en clair?

Etant donne' l'algorithme de chiffrement utilise', il est
trivial d'implementer une attaque a partir du chiffre' seul
(sans connaitre le clair ni faire de recherche exhaustive sur
la clef), a condition que la clef soit significativement plus courte que
le message a chiffrer.

Je comprends pour le clair, mais pour le chiffré ne faut-il pas se fier
au moins sur le clair ou sur la clef? Sinon je ne verrais pas vraiment
comment cela se pourrait, à moins de n'avoir que des caractères ascii zéro
dans le chiffré...
Pouvez-vous en donner le calcul pour trouver le clair (qui se répète 2
fois) ou la clef dans l'exemple suivant? Car à mon avis plusieurs clefs et
clair pourraient donner le même chiffré.

? ? ? = clef
? ? ? ? ? ? = texte clair
152 155 155 152 155 153 = chiffré


49 50 51 = clef
51 52 53 51 52 53 = texte clair
152 155 155 152 155 153 = chiffré

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

Si le clair ayant fourni le chiffre' est suffisemment "varie'" (i.e. si on
y trouve les sequences de deux octets consecutifs suivantes: [0x00, 0x00]
et [0xFF, 0xFF]), il est possible de retrouver la clef. Bien entendu si
l'intervalle de caracteres
utilise' pour le clair est plus reduit (exemple: caracteres ASCII
imprimables), l'attaque devient encore plus rapide
(i.e. il suffit d'un chiffre' de longueur moindre).
La technique consiste a majorer et minorer les valeurs de
k[i] (on se contentera du minorant si vous utilisez des modulo):

i = 0;
char min_k[3] = [0,0,0];
char max_k[3] = [0,0,0];
Pour( i = 0; i<nb_elements(c); i++){
si(c[i] < max_k[i%3]){
max_k[i%3] = c[i];
} //finsi
si(c[i] > min_k[i%3]){
min_k[i%3] = c[i];
} //finsi
} //fin tant que


max_k[0]-Q2;
max_k[1]-Q2;

Pour i = 0 ou i = 1 :
--> min_k[i] <= k[i] <= max_k[i]

On en deduit k[2].

[...]
Donc, un problème externe à l'algo et non de faire le traitement qui se
limite uniquement via une inversion de l'algo sans faire de comparaison
entre le chiffré et le clair.

Il faut que vous realisiez que les attaques a clair connu revelent une
faiblesse de l'algorithme utilise',

Dans notre exemple du début 'oui' puisque nous n'en sommes qu'à la 1re
étape ici. Cet algo n'est qu'un exemple et n'est pas à son achèvement
encore, puisque je l'ai mis pour qu'ensemble on puisse analyser la chose
étape par étape, pour enfin s'en inspirer éventuellement.

et pas un "probleme externe a l'algo" : en pratique, dans de nombreux cas,
une partie du clair peut etre devinee (cas typique : parties invariantes
des en-tetes de fichier). Les attaques a clair connu permettent alors de
retrouver la partie inconnue du fichier a partir d'une partie connue.

Je sais.

Il va falloir vous y
faire : un algo vulnerable a une attaque a clair connu est un algo
pourri

Pas nécessairement 'pourri' mais peut-être incomplet. Quand c'est pourri il
n'y a rien à faire avec ça.

(et je ne sais pas d'ou vous tenez ce terme abracadabrant d'"attaque
externe").
Enfin, comme l'ecrivait Christophe, il importe peu que l'on puisse
remonter a la clef d'origine si ce n'est pas elle qui sert au chiffrement.
Par exemple, dans le processus suivant :

Clef1 <--- Utilisateur

Clef2 <---[MD5]--- Clef1

Clef2
|
Chiffre'<--[Chiffrement]-- Clair

Ici je comprends pour certains cas, dépendant si on se limite à votre simple
schéma.

L'introduction d'une etape irreversible (le calcul d'une empreinte MD5)
ne perturbe en rien la cryptanalyse : en pratique, c'est Clef2 que l'on
recherche et qui sert a chiffrer. Pire, l'utilisation d'une empreinte
MD5 est susceptible de reduire la robustesse de l'algorithme en
introduisant des collisions (deux Clef1 peuvent donner la meme Clef2)
et en reduisant l'espace de recherche.

Je remercie donc les personnes qui on participées et qui participent à ce
fils de discussion qui dégage certaines choses instructives

Pourtant, vous semblez ignorer superbement le principal enseignement qui
se degage de cette discussion : un algorithme de chiffrement robuste ne
se concoit pas en quelques jours.

Disons que je n'ai pas à juger de la connaissance et l'intelligence de
certaines personnes. C'est comme des inventions qui ont été trouvées par
des gens pas très instruits.

D'autant moins quand le concepteur
est inexperimente'. Jusqu'ici, tout contribue a montrer que votre algo ne
vaut pas tripette et vous persistez a vouloir l'utiliser plutot que de
vous fier a des algorithmes eprouves. C'est dommage.

Le simple algo présenté ici n'est pas l'algo dans AllCrypter, même si on
le retrouve en partie. J'ai présenté le 'simple algo' ici afin de faire
participer des personnes et ensemble à voir la façon idéale et le plus
simple possible de trouver une solution en analysant tous les aspects d'un
bon algo de cryptage aussi simple soit-il.

Donc en conclusion, mon but est plutôt de recevoir ou de donner des
commentaires accompagnés d'éventuelles SOLUTIONS qui sont expliquées par de
simples petits exemples. Je pense que ce forum est là pour ce genre de
démarche aussi. Pour certain, c'est un plaisir d'étudier et d'essayer de
créer un algo; je ne les décourage donc pas en disant qu'il y a d'autres
algos qu'on peut utiliser sur le marché et qui ont fait leur preuve, même si
la personne veut en faire un et le commercialiser.



Passez une bonne journée.

r.h.

Le déchiffrement est défini par :
...
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3

ici que signifie le '-2' ? Car en algèbre ça se définirait ainsi:
m1 = (c1 - c2 + c3 ) - (2*k1) + ( k2 - k3) et de cette façon le résultat
ne correspond pas.

J'ai revérifié mes calculs, ça a l'air pourtant bon. Tu interprètes
bien le sens de la multiplication. les m1, m2 et autres c2 et c3 sont des
nombres (des scalaires, par oppositions aux matrices) qui se multiplient
bien entre eux.
Les M et C sont des vecteurs.

Voici le détail d'un calcul avec M chiffré en C avec la clé K :
C=[8;47;145]
K=[1;2;99]
m1 = c1-c2 +c3 -2*k1+k2-k3
= 8 -47 +145 -2*1 +2 -99
= 7

Au final on/je trouve bien que M=[7;0;45]

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