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

...
Puis, il ajoute: "Autant faire simplement un XOR sur le message."

Puis encore: "... C'est plus simple, plus rapide, et c'est AUSSI PEU
SOLIDE. (length(clé) length(message))."

J'avais dit: "J'attends donc vos suggestions, et vous donne un test pour
trouver soit la clef (k) ou le clair (2m)." Et on m'a répondu (je
précise que c'est à l'étape 3 du 'Simple algo'): "Ce groupe vous a
déjà montré à plusieurs reprises les faiblesses de votre algo."

Ceci étant dit, faudrait expliquer pourquoi cet algo à l'étape
actuel
(étape 3) serait AUSSI FAIBLE qu'aux étapes 1 et 2. Pourtant personne
n'a pu le casser encore cette étape 3 (je ne dis pas que c'est
impossible).

Je sais faire.
Si je sais faire, les autres aussi. C'est juste une
histoire de temps et de compétences. Je n'ai pas réussi à produire une
attaque en clair choisi mathématiquement solide, c'est tout. La totalité
des autres argumentations est toujours valable. D'ailleurs, j'ai fourni
une preuve dans un autre post :

<citation id="crs7cv$24dj$1@biggoron.nerim.net">
? ? ? ? = k
8 12 21 = 1m
32 51 62 = 1c

Là, d'accord : k = [1;5;68;225]
sinon, k = [1;5;5;13] ?
peut-être, k = [1;5;85;45] ?
</citation>

S'il est possible de le casser alors ça me ferait très
plaisir qu'il soit cassé le plus vite possible afin que je réfléchisse
à corriger la 'soit disante faiblesse' en tenant compte de vos
commentaires (Oui, oui! Si je suis à l'étape 3 déjà, c'est qu'à
quelque part j'ai lu et réfléchis).

Pour ma part, j'ai étudié ta méthode parce que j'y avais un intérêt :
potasser mon algèbre linéaire, réviser les fondements de la cryptologie
par exemple. Tout ça gratuitement.

J'ai déjà dis et démontré que ton procédé est faible. Mes aptitudes
et mon bon sens ne devraient plus être mises en doute (par toi). Ainsi,
je te dis que ta dernière mouture est faible, je le vois à l'oeil nu. La
réponse est dans n'importe quelle source d'information, à condition de
la comprendre.

Je tiens à remercier 'Christophe HENRY' pour avoir avoué sa limite
actuelle (dans les maths) disant qu'il n'arrive pas casser le 'Simple
algo' à l'étape 3.

Pas de remerciements. C'est normal. Et surtout, ton procédé est
quasi-cryptanalysé. Je souhaite juste en finir avec l'équation triviale
qui me bloque pour obtenir une solution belle et nette comme je les aimes
tant : du genre donner TOUTES les clés possibles plutôt qu'une seule
comme je l'ai fait lorsque tu as passé ta clé sur 4 octets :-*

...
J'aimerais bien qu'un spécialiste en cryptologie ou en mathématique nous
dise son avis sur la possibilité du cassage du 'Simple algo' à l'étape
3.

Marrant de séparer crypto et maths. Autant imaginer un auteur
(ie crypto) de romans français ne parlant (ie maths) pas le français :-/

Je me demande si j'ai bien saisi "exactement" ce que vous souhaitez
faire dans ce nouvel algo... Encore une fois, comme Christophe Henry,
(j'en profite pour passer un coucou, ça fait 2 fois dans le même
message quand même ! :D)

Je ne comprends pas pourquoi vous me faites un coucou, puisque j'ai
déjà
expliqué plus d'une fois le but du développement de ce 'Simple algo'
dans ce fil de discussion. Or, qui doit recevoir les coucous? :-)

Nan ! Ce n'est pas pour toi le coucou. C'est juste que la répétition des
patronymes peut avoir tendance à privilégier la personne sur les idées.
Alors pour en amenuiser les conséquences, on le révèle avec une touche
d'humour ;-)

En fait, c'est la troisième en comptant la citation de Raymond. Le
quota diminue puisque dans ce post, mon patronyme n'est référencé
qu'une seule fois.
Je n'en dirait pas autant de Mister Jack qui se retrouve de nombreuses
fois (Mister Jack Mister Jack Mister Jack Mister Jack Mister Jack) sans
aucune justification. J'en profite donc pour passer aussi un coucou ;-)

Alors 'coucou'! :-)

Le coucou, il était pour Mister Jack !

Au niveau du compte :
Chritophe HENRY : 3
Mister Jack : 6
Bill Gates : 1

Plus fort que BG :-) Et je trouve que Jack prends la grosse tête 8-)

Je vous ai dis ça car j'ai l'impression que vous en faites un peu à
votre tête sans vouloir prendre en considération ce que certains vous
suggèrent. (case, Vengeur, Erwann,...)

Disons que je vous lis, je réfléchis avec ma tête et essais de voir
le
pour et le contre. Mais ce n'est pas parce qu'on me dit un tel ou un tel
a dit ceci (même si ça serait Bill Gates ou le Président des
Etats-Unis) qu'il faut que je croie la même chose ou que j'abandonne mon
projet du 'Simple algo'.

Je veux bien tenir ce raisonnement lorsque les conseillers en question ont
un intérêt à gouverner notre pensée (élections, émission de
"culture" télévisuelle sur M6, Linux ou Windows, etc.) mais là,
personne n'a d'intérêt dans ce qu'il écrit. C'est presque juste pour le
plaisir.
Une dame à la TV te dis qu'il va faire beau demain, et tu la crois. Alors
que de nombreux intervenants te prédisent un mauvais temps, tu ne les
crois pas.

Je ne dis pas que les gens n'ont pas de bonnes
opinions quelque fois, mais si on me dis que mon algo ne vaut rien alors
moi je continue à avancer sans écouter ce genre de voie.

<schadok>Ga Bu Zo Meu ?</schadok>
J'ai lu (et normalement, compris) les contributions des auteurs ayant
écrit des programmes pour cryptanalyser tes procédés. Je vais
totalement dans leur sens parce que j'aurais fait pareil.

Je suis du
genre à ne pas être un mouton qui suis tout ce que j'entends même si
c'est la majorité; je vais dans la direction que je juge devoir aller
selon la compréhension du moment que j'ai. Et si je me trompe alors
j'apprendrai de cette façon aussi.

Certes. Mais tu négliges un GROS détail : les contributeurs du forums
ont derrière eux les centaines d'années de sciences mathématiques dont
ils se servent pour argumenter. Jusqu'à mes démonstrations et
applications qui ont démontré la faiblesse du procédé. Or, si je
m'avère compétent (à ton sens), les autres le sont au moins autant.

Raymond, pourquoi ai-je l'impression que tu implémentes une fonction de
hachage en ce qui concerne nos remarques ?

??? une fonction de hachage!#!!?##? Je ne suis pas sûr de comprendre.

C'est là où je voulais en arriver : tu n'as pas les connaissances de
base pour construire ce genre d'algorithme dont les termes élémentaires
t'échappent.

Supposons que nous (on dit tous la même chose, donc : nous)
ayons raison. Nous possédons la science nécessaire pour se l'expliquer
entre nous et tout autre personne culturée. Mais tu ne peux pas
comprendre et, c'est le plus génant, accorder de valeur à nos écrits
parce que tu ne les comprends pas. C'est dommage.

Si je te dis qu'il est difficile d'aller en haut du mont Blanc sans
outillage, tu me crois parce que nous avons la même logique :
température, effort physique, risques, avalanche...
Ici c'est pareil, sauf que tu ne sens pas (encore) la fatigue.

...Ces fils sont à la suite justement de l'annonce d'AllCrypter
dans ce groupe de discussion,

Ca s'appelle du SPAM, en violation avec ma petite pensée à moi que j'ai
sur l'usage des forums, et, en violation avec les chartes régissant la
hiérarchie fr.*.
Tu as d'ailleurs répété l'offense sur au moins un autre forum.

Au lieu de dire : "j'ai un algo qui tue, qui veut me le casser ?", tu as
posté un message à caractère commercial crade.

et mon but est de
développer ce 'Simple algo' en sorte que je le mette ou m'en inspire
pour la version 3 d'AllCrypter. Je tiens à ce que les gens utilisant
AllCrypter ait un logiciel sur lequel ils peuvent compter. C'est
pourquoi je veille à son amélioration POUR une version 3 interdisant
les attaques à clair ou chiffré connue ou d'autres sortes d'attaques.
Moi, j'y crois, et c'est à quoi je mets mon énergie ici.

Tout ce que tu vas arriver à faire c'est épuiser les compétences (dans
mon cas) et les énergies (de tous les contributeurs). Tout cela est fait
gratos, ne l'oublie pas. L'énergie totale est limitée et tends à
s'épuiser.

Réussir à "vaincre" des bénévoles débutants (ou des pros du pot avec un
temps limité) ne garanti en rien l'efficacité de ton procédé. Par
exemple (j'ai lu tes avis sur les "paris") si tu mettais une somme en
jeux, ça deviendrait plus intéressant. Rémunérer le travail qui
réussi...

Je vous assure que j'ai pris en considération plusieurs de vos
remarques, même si je n'en fait pas toujours suite. De plus,
j'apprécie grandement vos contributions dans ce fil (étape 1 et 2, et
celle-ci). Dès le début j'ai apprécié la façon dont vous avez fait
vos interventions, même si la profondeur de vos calculs me laissait
quelque fois un peu derrière :-) Vous êtes même celui qui a le plus
souvent contribué et il est évident que vous n'êtes pas un débutant
en la matière.

Tu vas rire : je suis _débutant_ en la matière. Ce n'est pas que je sois
modeste, mais juste réaliste. La crypto est pour moi un amusement, pas
mon métier principal. Imagine les autres...
C'est comme si un allemand (parlant très bien l'allemand) te disait
que tu es très fort parce que tu parles français :-o

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

On Tue, 11 Jan 2005, Pierre Vandevennne wrote:

Tiens, t'as pas zappé le thread toi non plus? :)

"Raymond H." <divers_rh@hotmail.com> wrote in
news:SYeEd.1097$b64.65667@news20.bellglobal.com:

construire étape par étape un simple algo qui passerait tous les tests
d'attaques. Il n'est pas question ici de l'algo déjà dans mon

N'avez qu'à faire un réseau de feistel et ajouter des tours.

Trop facile. Et le double XOR, tu le mets où? ;)

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
DP>à partir de quand n'est-on plus un neuneu? est-ce que ça se soigne?
C'est une variété de maladie infantile la réponse est donc oui. La
réponse à la question est-ce que ça se guérit est ; pas toujours.
-+- JdC in : Guide du Neuneu Usenetien - La maladie infantile -+-

Salut !

Et en parlant de la logique, vous pouvez utiliser la vôtre pour tenter
de savoir si l'algo est incassable ou non. Personnellement, je ne voie pas
comment quelqu'un pourrait casser cet algo.

Vous pourriez faire un récapitulatif clair de l'ensemble des étapes de
chiffrement à partir du clair pour arriver au chiffré ? (génération de
la clé, utilisation de la clé, chiffrement en lui-même...). Merci.
Personellement ça me serait très utile pour vous donner un avis objectif.

Si vous le pouvez alors tant
mieux car vaut mieux que l'algo soit cassé maintenant plutôt que dans 5 ans
par exemple. Et si vous le casser alors j'aurai intérêt à réfléchir sur le
calcul que vous aurez effectué pour ce faire.

J'avais vu un court article de Guillermito sur l'utilisation des
méthodes statistiques pour aider à retrouver des informations cachées
dans un fichier. Essayez de le retrouver. Ce genre de méthodes peut
aussi être utilisé pour casser un chiffrement.
C'est pour celà, par exemple, que même si on ne pouvait pas démonter
votre algo en 3 lignes de calculs, il serait peut-être faible tout de même.

Cordialement,
--
Mister Jack (MJ)
Vous ne pouvez faire confiance à un algorithme de cryptage créé par
quelqu'un qui n'a pas "fait ses classes" en cassant des codes.
-+- Brian Snow, cryptographe à la NSA -+-

Le Tue, 11 Jan 2005 11:01:54 +0100, Erwann ABALEA a écrit :

N'avez qu'à faire un réseau de feistel et ajouter des tours.
Trop facile. Et le double XOR, tu le mets où? ;)

J'ai bien une idée, mais bon... :)))


--
Je proposerai de tenter d'y remédier en insérant systématiquement
un portrait, une photo de soi dans toutes les contributions à
venir. Certes cela fait 10 Mo de plus à chaque envoi.
-+-JP in Guide du Neuneu d'Usenet : ketenafout la bande passante ?-+-

??? une fonction de hachage!#!!?##? Je ne suis pas sûr de comprendre. Je
n'ai aucune pensée de faire du tort à personne, ni de m'infiltrer dans des
systèmes d'autrui; cela ne m'intéresse pas et j'ai autres choses de plus
important à faire.

MDR !

Dans "hachage" il y a "hache", c'est ça ?

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

"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
41e1bd85$0$8047$8fcfb975@news.wanadoo.fr...

dans l'affirmative, ne refait-on pas une masque jetable ?
si la méthode a son originalité propre, comment malgré tout
procéderez-vous à l'échange de clé ?

A mon humble avis, il devrait recourir à l'OTP pour la phase "chiffrement
symétrique".

Donc, avec du xor. J'ai pensé à utiliser le xor combiné avec une
addition avant et après le xor, et rallonger la clef de session en rapport
avec le clair.

Un exemple:

Clef de session initiale générée par le logiciel: 2-3

Clair: 23-45-32



(2 + (3 xor 23) + 45) mod 256 = le prochain caractère qui vient juste après
2-3.

-Clef de session prolongée: 2-3-67

Ensuite, je crypte un caractère du clair à partir des deux derniers
caractères de la clef de session (k1=3 ; k2g ; m1= 45 ; m2= 32).

-c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256 (ici j'ai mis 'c1' en
exemple).
Je répète pour ajouter un autre caractère à la clef de session, puis je
continue. Je pourrais faire ainsi jusqu'à la fin du clair. C'est une idée
comme ça, mais je ne pourrai pas adopter cette idée pour la raison que le
déchiffrement doit débuter par la fin; donc un problème avec la clef de
session ici.



Le problème pourrait être résolu en utilisant la clef de session
initiale qui elle, serait transformée sans cesse au fur et à mesure du
chiffrage, et ainsi je n'aurais qu'à enregistrer la clef de session finale
(les derniers caractères générés dans la clef de session à la fin du
chiffrage, le même nombre de caractères que la clef de session initiale et
de la phrase de passe).



Exemple:


-Clef de session initiale générée par le logiciel: 2-3-4 (durant le
processus de modification de cette clef de session, on ne conservera que les
x derniers caractères, donc on ne conservera que le même nombre de
caractères que la phrase de passe. Ainsi, au fur et à mesure qu'on ajoute
un caractère à la fin de la clef de session on en supprime une au début).



-Clair: 23-45-32-26-123-225-...



donc:

S = 2-3-4 = k dans l'exemple.

M = 23-45-32-26-123-225-...



c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256 donc 79=(((2 + 3 + 23 +
45) xor 3) + 2) Mod 256

c2=(((k2 + k3 + m2 + m3) xor k3) + k2) Mod 256 donc 83=(((3 + 4 + 45 +
32) xor 4) + 3) Mod 256

((k2 + k3) xor m2) + m3) mod 256 = ((3 + 4) xor 45) + 32) mod 256 = 74
donc 3-4-74 [rendu au bout on ajoute un caractère à la fin et on en
supprime un au début et on recommence à crypter à partir du 1er caractère de
la clef de session]

S = 3-4-74 = k

c3=(((k1 + k2 + m3 + m4) xor k2) + k1) Mod 256 donc 72=(((3 + 4 + 32 +
26) xor 4) + 3) Mod 256

c4=(((k2 + k3 + m4 + m5) xor k3) + k2) Mod 256 donc 173=(((4 + 74 + 26 +
123) xor 74) + 4) Mod 256

((k2 + k3) xor m4) + m5) mod 256 = ((4 + 74) xor 26) + 123) mod 256 = 74
donc 4-74-207 [rendu au bout on ajoute un caractère à la fin et on en
supprime un au début et on recommence à crypter à partir du 1er caractère de
la clef de session]

S = 4-74-207 = k

c5=(((k1 + k2 + m5 + m6) xor k2) + k1) Mod 256 donc (484) donc 228=(((4 +
74 + 123 + 225) xor 74) + 4) Mod 256

etc...



Donc, la phrase de passe et la clef de session finale seront cryptées
ensemble à la fin du chiffrage et joint au chiffrage pour être enregistrées
dans un fichier. Cette clef de session finale dans notre exemple serait
4-74-207 et non 2-3-4. On conserve donc la clef de session finale puisqu'il
faudra débuter le déchiffrage par la fin du fichier chiffré.

Or, après avoir écrit sa clef, l'utilisateur clique sur le bouton
'Crypter' pour que le logiciel produise aléatoirement (au hasard) une
chaîne
d'une certaine longueur (exemple: 1024 bits ou moins) pour servir à
crypter
le clair par la suite.

L'utilisateur aurait pu se mettre en tenue adéquate, ouvrir les fenêtres
en grand ou nettoyer la cuisine...

Je mettais l'accent sur le fait que la clef de session n'était pas
générée par l'événement 'Change' du TextBox au fur et à mesure qu'on écrit
la 'phrase de passe', mais seulement lors du clic sur 'Crypter'. Je disais
ça pour les programmeurs. Mais peu importe.

Donc, dans un premier temps, la clef modifiée (identificateur de la
clef) est cryptée avec la chaîne générée, et cela selon le même algo que
le
clair. Mais, le clair est crypté à partir de la chaîne, puis la clef et
la
chaîne générée cryptées sont ajoutées au chiffré.

Quelles sont les différences entre :
"clef modifiée"
"identificateur de la clé"
"chaîne"
"chaîne générée"
"algo"
"chiffré"

1- La clef est la 'phrase de passe'.

2- Lorsque la 'phrase de passe' est modifiée par un calcul non inversible,
elle est appelée 'code d'identification' (c'était la clef modifiée). Car ce
code indique uniquement si la 'phrase de passe' est la bonne ou non lors du
déchiffrage. Si oui, alors le déchiffrage débute.
3- La chaîne générée via le clique sur le bouton 'Crypter' est la 'clef de
session initiale' qui se crée au début (elle aurait le même nombre de
caractères que la phrase de passe).
4- Lorsque des caractères sont ajoutées à la clef de session initiale alors
elle est appelée clef de session. À la fin du chiffrage, elle est appelée
clef de session finale.
5- L'algo = l'ensemble des calculs effectués pour le chiffrage/déchiffrage.
6- Le chiffré est le cryptogramme (les données cryptées).

Tu m'aiderais en définissant ces termes précisemment. Par exemple, que
doit contenir _à_terme_ le chiffré ?

Donc, lors du clic sur 'Crypter', une chaîne est générée, puis
la clef est ajoutée à cette chaîne pour être crypté ensemble à partir de
cette même clef (on pourrait faire un xor avec les deux et stoquer le
résultat seulement). Enfin, le reste serait crypté à partir de la chaîne
générée et non à partir de la clef.

Je ne comprends pas cette partie. J'ai au moins quatre interprétations
possibles.

J'ai modifié un peu le procédé dans ce message.

1- On écrit la phrase de passe.

2- On clique pour crypter:

a: le code d'indentification de la phrase de passe est créé à partir de
la phrase de passe (ce code est utilisé seulement lorsqu'on clique pour
décrypter).

b: la clef de session initiale est créée au hasard par le logiciel (elle
aurait la même longueur que la phrase de passe).

c: chaque caractère du clair est crypté jusqu'à ce qu'on arrive au
dernier caractère de la clef de session.

d: un caractère s'ajoute à la clef de session et on supprime le 1er.

e: les opérations c et d se répètent jusqu'au dernier caractère du clair
crypté.

f: le code d'indentification (qui identifie la phrase de passe au début
du déchiffrement) et la clef de session finale sont cryptées ensemble à
partir de la phrase de passe.

g: le code d'indentification et la clef de session finale qui ont été
cryptés sont ajoutés au chiffré, et le tout est enregistré dans un fichier.



1- On écrit la phrase de passe.

2- On clique pour décrypter

a: le code d'indentification et la clef de session finale qui ont été
cryptés sont décryptés à partir de la phrase de passe.

b: le code d'indentification de la phrase de passe de l'étape un (1)
crée un code d'identification, et ce code d'identification est comparée avec
le code d'identification qui a été décrypté à l'étape a. Si les deux codes
d'identification correspondent alors le déchiffrement est accepté.

c: le dernier caractère de la clef de session finale' est utilisé pour
décrypter le dernier caractère du chiffré.

d: chaque caractère du chiffré est décrypté (de la fin vers le début)
jusqu'à ce qu'on arrive au début de la clef de session.

e: le dernier caractère de la clef de session est supprimé puis un
nouveau caractère est ajouté au début de la clef de session.

f: les opérations d et e se répètent jusqu'au premier caractère à
décrypter dans le chiffré entier.

Ceci aurait comme avantage qu'une personne pourrait utiliser la même
clef plusieurs fois pour crypter un même clair, et le chiffré donnerait
d'une fois à l'autre un résultat différent.

J'ai de très grands doutes sur cette méthode, mais j'attendrai d'avoir
ta définition précise des termes pour argumenter.

D'accord.

Ainsi, cela empêcherait de
faire des comparaisons de clairs et de chiffrés, ceci empêcherait aussi
de
faire des comparaisons de portions du chiffré.

Je suis persuadé du contraire. Certaines attaques que j'ai prouvées se
passent de la clé. La dernière autorise carrément l'usage d'une
quasi infinité de clé (de session) sans connaître la clé de
l'utilisateur (de passe).
J'argumentrai plus précisement lorsque j'aurai compris tous tes termes.

Il ne faut pas oublier que le principe de la clef de session que j'ai
expliqué plus haut fonctionne avec le 'Simple algo' de l'étape 3 qu'on a pas
réussi encore à casser.

L'utilisateur a sa phrase de passe : P
Le programme génère une clé de session : S
Le clair est : M
Le chiffré est : C
le chiffrement est indiqué par un /, ex: M/S signifie
que le clair M est chiffré avec S.
Le déchiffrement est indiqué par un .
La concaténation de données est formalisée par : {A}{B}, B étant
rajouté à A.

L'algorithme envoie génère donc : C = { M/S }{ S/P }

Pci= La phrase de passe transformée en code d'identification.
C'est la clef de session finale qui est cryptée.
Dans le nouvel exemple, l'algorithme génère comme résultat: C = { M/S }{
{{Pci}{S}}/P }

Le déchiffrement global consiste donc à déchiffrer tout d'abord la
clé de session : (S/P)P = S.
Ensuite déchiffrer, la partie de gauche : (M/S)S = M.

J'ai bon ? En fait, ça m'aiderait que tu adoptes un certain formalisme.

Le déchiffrement global consisterait à déchiffrer ensemble tout d'abord
le code d'identification (Pc) et la clé de session finale: ({Pci}{S}/P)P =
{Pci}{S}.
Puis on déchiffre la partie de gauche : (M/S)S = M

Les cryptosystèmes asymétriques sont faits sur une idée semblable...

Vous parlez des algos à clef privée et publique? Ils sont sans
exception tous fait sur un model semblable?


Bonne journée.

Raymond H.

"Mister Jack" <news@mjcie.net> a écrit dans le message de news:
41e3a8da$0$29904$636a15ce@news.free.fr...

Salut !

Et en parlant de la logique, vous pouvez utiliser la vôtre pour
tenter de savoir si l'algo est incassable ou non. Personnellement, je ne
voie pas comment quelqu'un pourrait casser cet algo.

Vous pourriez faire un récapitulatif clair de l'ensemble des étapes de
chiffrement à partir du clair pour arriver au chiffré ? (génération de la
clé, utilisation de la clé, chiffrement en lui-même...). Merci.
Personellement ça me serait très utile pour vous donner un avis objectif.

Bonjour,

en effet, faudrait bien que je le fasse à la conclusion de l'algo.
Mais, à l'heure actuelle, l'algo n'est pas terminée puisque la partie de
l'algo pour générer une clef de session allant jusqu'à la longueur du clair
(par section renouvelée ayant toujours la même longueur que la phrase de
passe comme expliqué ailleurs) n'est pas accomplie. Je viens juste d'en
donner un exemple en réponse à un message à notre ami Christophe Henry. Je
pense que c'est l'étape la plus critique à construire, surtout quand on
pense qu'il faut que la clef de session ait la même qualité qu'une clef
unique de la même longueur que le clair sans répétition de partie.

Si vous le pouvez alors tant mieux car vaut mieux que l'algo soit cassé
maintenant plutôt que dans 5 ans par exemple. Et si vous le casser alors
j'aurai intérêt à réfléchir sur le calcul que vous aurez effectué pour ce
faire.

J'avais vu un court article de Guillermito sur l'utilisation des méthodes
statistiques pour aider à retrouver des informations cachées dans un
fichier. Essayez de le retrouver. Ce genre de méthodes peut aussi être
utilisé pour casser un chiffrement.
C'est pour celà, par exemple, que même si on ne pouvait pas démonter votre
algo en 3 lignes de calculs, il serait peut-être faible tout de même.

Cordialement,

Merci pour le l'info. Je vais chercher afin de regarder ça.
Bonne journée :-)
Raymond H.

Salut !

J'ajoute un soous-fil à cause d'un truc qui me chagrine dans l'algo tel
que décrit précédemment.

c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256
c2=(((k2 + k3 + m2 + m3) xor k3) + k2) Mod 256
c3=(((k3 + k4 + m3 + k4 ) xor k4) + k3) Mod 256 (k4 remplace aussi m4)

on va faire joujou avec c1, par exemple. Au lieu de travailler sur un
octet on va travailler sur un bit. En particulier le bit 0 (zéro).
Je prends ici l'ordre des bits 76543210 et appelle 0 'le premier'.

on prendra '^' qui signifie un 'ou excusif' (XOR) et '.' qui signifie un
'et' (AND).

On a :
c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.

Je voulais continuer avec le deuxième bit (1), mais la simplification ne
donne pas quelque chose d'exploitable à première vue. J'ai essayé de
passer ça sous MappleV pour voir si j'ai loupé un truc, mais il plante
sur l'évaluation d'un gros bsimp()... pauvre MappleV... :p

Bon, sinon on a déjà 1 bit sur 8 d'inexploité par la clé donc, on double
déjà le nombre de clés valides grâce à ce bit du premier octet.
Vérification avec des clés valides :

1 : K={1,5,4,225} 57 : K={2,5,4,225}
2 : K={1,5,5,13} 58 : K={2,5,5,13}
3 : K={1,5,20,1} 59 : K={2,5,20,1}
4 : K={1,5,21,173} 60 : K={2,5,21,173}
5 : K={1,5,68,225} 61 : K={2,5,68,225}
6 : K={1,5,69,141} 62 : K={2,5,69,141}
7 : K={1,5,84,129} 63 : K={2,5,84,129}
8 : K={1,5,85,45} 64 : K={2,5,85,45}
9 : K={1,5,132,225} 65 : K={2,5,132,225}
10 : K={1,5,133,13} 66 : K={2,5,133,13}
11 : K={1,5,148,1} 67 : K={2,5,148,1}
12 : K={1,5,149,173} 68 : K={2,5,149,173}
13 : K={1,5,196,225} 69 : K={2,5,196,225}
14 : K={1,5,197,141} 70 : K={2,5,197,141}
15 : K={1,5,212,129} 71 : K={2,5,212,129}
16 : K={1,5,213,45} 72 : K={2,5,213,45}
...

Hé oui, on retrouve toujours une correspondance avec tous les octets
identiques sauf le premier où au moins son premier bit change. Ca se
vérifie sur l'ensemble des clés, mais je n'ai pas mis les 640 ici ;-)

Il y a encore pas mal de choses de ce genre, on pourra chercher à les
mettre en évidence.

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

Bonjour Mister Jack,

"Mister Jack" <news@mjcie.net> a écrit dans le message de news:
41e4399a$0$11943$636a15ce@news.free.fr...

Salut !

J'ajoute un soous-fil à cause d'un truc qui me chagrine dans l'algo tel
que décrit précédemment.

c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256
c2=(((k2 + k3 + m2 + m3) xor k3) + k2) Mod 256
c3=(((k3 + k4 + m3 + k4 ) xor k4) + k3) Mod 256 (k4 remplace aussi m4)

on va faire joujou avec c1, par exemple. Au lieu de travailler sur un
octet on va travailler sur un bit. En particulier le bit 0 (zéro).
Je prends ici l'ordre des bits 76543210 et appelle 0 'le premier'.

on prendra '^' qui signifie un 'ou excusif' (XOR) et '.' qui signifie un
'et' (AND).

On a :
c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.

Juste une question. Pourquoi remplacez-vous les '+' de la ligne

suivante par des 'xor'? Puisque ça ne fait pas le même calcul ni ne donne
le même résultat. Ce pourrait-il que vous pensez que les '+' sont des 'xor'
ici?
c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256

Bonne journée.
Raymond H.

Salut !

J'ajoute un soous-fil à cause d'un truc qui me chagrine dans l'algo tel
que décrit précédemment.
...
On a :
c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.

Le premier bit du chiffré est ainsi fonction uniquement du clair.

Je voulais continuer avec le deuxième bit (1), mais la simplification ne
donne pas quelque chose d'exploitable à première vue. J'ai essayé de
passer ça sous MappleV pour voir si j'ai loupé un truc, mais il plante
sur l'évaluation d'un gros bsimp()... pauvre MappleV... :p

J'ai des équations dont l'archétype est : x + a = x XOR b (a,b connus).

Bon, sinon on a déjà 1 bit sur 8 d'inexploité par la clé

Je ne crois pas, dans le cas général. Si changer k1[0] ne change pas
c1[0], une retenue pourra se propager et perturber c1.

Contre-exemple :
M = [8;12;21]
K = [7;8;9;10]
-->SAxor(M,K)
! 50 !
! 67 !
! 65 !
-->SAxor(M,K+[1;0;0;0])
! 52 !
! 67 !
! 65 !
-->SAxor(M,K+[-1;0;0;0])
! 48 !
! 67 !
! 65 !

donc, on double
déjà le nombre de clés valides grâce à ce bit du premier octet.
Vérification avec des clés valides :

1 : K={1,5,4,225} 57 : K={2,5,4,225}
2 : K={1,5,5,13} 58 : K={2,5,5,13}
...

A mon avis, cela est dû au fait que c12, avec un unique 1 placé au
rang 5.

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