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

"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de
news:EcsFd.30659$b64.895907@news20.bellglobal.com...

Je dis que vous avez une CERTAINE compétence comme beaucoup ont, y
compris moi. Chacun à son propre niveau. Les uns plus que d'autres.
De plus, je ne néglige pas tout ce que je lis, et je ne met pas pour
autant

TOUTES ma confiances dans les scientifiques. Prenez par exemple certaines
'lois de la physique' concernant le mouvement perpétuel, et bien d'autres.
Des professeurs universitaires enseignent que le mouvement perpétuel est
impossible et pourtant on a la preuve du contraire: sans parler de
l'invention en France; regardons la terre qui fait le tour du soleil.
Assez

ridicule quelque fois certaines lois non de la physique mais des hommes
sur

la physique. Ce n'est qu'un exemple parmi tant d'autres. Aussi, les
inventeurs n'étaient pas tous très instruits. Passons...

Ca faisait longtemps. Et les Américains ne sont jamais allés sur la Lune,
aussi. La preuve, c'est que la Lune est habitée, et qu'il ne l'on pas dit,
ce qui prouve qu'il n'y sont pas allés. Franchement Raymond, tu déclines.

<couic>

Mais, concernant le 'hachage' ou 'hash', j'ai déjà parlé du code
d'identification généré par la phrase de passe par un certain calcul.
N'est-ce pas d'une certaine façon en rapport avec le hachage? Puisque
c'est

de façon non inversible. Si je prend le MD5, il peut pourtant produire
des

collisions et n'est donc plus considéré comme sûr. Voir à
http://fr.wikipedia.org/wiki/Fonction_de_hash à la section 'Fonction de
hash

cryptographique'.

Remarque à 2 centimes, c'est pas parce que MD5 a un petit trou que tout
"algorithme" (entre guillemets et avec des pincettes) qui a un gros trou
peut être appelé "Fonction de hash cryptographique", hein, on est d'accord ?
Le syllogisme "une fonction de hachage cryptographique est un calcul non
inversible, le calcul de Raymond est non inversible par Raymond, donc le
calcul de Raymond est une fonction de hash cryptographique" reste à
démontrer, n'est-ce pas ?

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.

Je ne vois vraiment pas le but de ce commentaire. Si vous avez la
science nécessaire pour expliquer, pourquoi ne pas vous faire comprendre
simplement en utilisant des mots communs de tous les jours pour tous?
Moi,

je parle français et je ne connais pas tous les mots français, ai-je un
manque de connaissance pour m'expliquer avec d'autres mots plus simples?
Par

exemple, je suis guitariste et je ne lis pas les notes de musique et les
notes ne m'intéressent pas non plus. Mais par contre à la fin de
l'adolescence (il y a quelques décennies) je jouais assez bien de la
guitare

et je jouais avec un groupe dans des endroits annoncés à la télé et on
disait que j'étais professionnel. Or, je joue à l'oreille. Cela fait-il
de

moi un incompétent ou un moins qu'un débutant et de ce fait incapable de
m'adapter avec d'autres guitaristes?

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.

Lisez les premiers messages du 'Simple algo'. J'ai tenté d'expliquer
étape par étape à AMcD le procédé pour trouver le clair à partir de la
clef

et du chiffré; j'ai tenté de le faire étape par étape par de simples
calculs, puis vous avez ajouté des calculs plus compliqués (et cela je le
respecte). 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.

Tous ceci pour vous dire que vous pouvez employer un langage plus
simple

lorsque vous pensez que moi ou d'autres ne sommes pas à la hauteur de vos
compétences.

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, les cours de maths sont plutôt loin... Mais il n'empêche
que la *lecture* des ses posts est infiniment plus claire que les tiens
parce qu'il utilise un langage adapté, et in-fine ses démonstrations sont
donc accessibles aux lecteurs qui fait l'effort de ressortir ses cours. 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).

...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

Et voilà! Votre pensée. 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. Et que ça s'appelle ou ne s'appelle pas du SPAM dans ton
vocabulaire ne change rien au fait qu'une publicité pour un logiciel
commercial est toujours limite limite par rapport à l'étiquette, mais
effectivement ce n'est pas le propos.

<snip>

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

Exactement. Ca c'est le propos.

Ca va à part ça? Je dis cela pour vous faire réfléchir sur le
pourquoi

vous m'écrivez tout cela. Car ce n'est pas très intéressant de se faire
piquer de temps en temps, surtout à la suite de phrases que j'aurais
écrites

pour vous faire plaisir comme en disant que vous n'êtes pas débutant en
matière de cryptologie (et non dans un métier).

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

<snip>

Et moi aussi je le fais gratos. Je dis cela car le mot 'gratos' est
venu plus d'une fois sur le forum. Or, ce n'est pas un forum payant ici.
Il sert à des échanges d'idées et à s'entraider. Alors, pourquoi parler
du

mot 'gratos'. Si l'argent ou le temps causent problème à certaines
personnes, et bien ce forum n'est pas obligatoire. Or, ce forum est
autant

pour aider les gens sur un logiciel commercial ou non ou autres.

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.


--
Johann

"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de
news:y0tFd.30661$b64.899273@news20.bellglobal.com...

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

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

Effectivement, c'est beaucoup mieux qu'il soit non inversible. On appelle ça
un garbagge collector d'ailleurs.

--
Johann

C'est une belle philosophie Schadok.
A quoi ça sert d'agrandir l'espace des clés d'un ordre de grandeur
(dimension) si c'est pour augmenter les clés similaires d'autant.
Avec une clé de même longueur que le clair, la correspondance est
unique. Dès lors que la clé est plus longue que le clair, il existe
systématiquement des clés équivalentes dans la même proportion.

Excusez mon erreur. Ce n'est pas un grand nombre de clefs différentes
pour un clair qui est mieux mais plutôt un grand nombre de clefs et clairs
différents pour un même chiffré.

Pour n'importe quel chiffré donné, pour n'importe quel clair donné il
existe toujours au moins une clé allant de l'un à l'autre. De même,
pour n'importe quel clé donnée, pour n'importe quel chiffré donné, il
existe toujours un clair qui correspond.

A partir d'un chiffré, il est _impossible_ de retrouver quelque clair ou
quelque chiffré. A peu de choses près, puisqu'il y a au moins un
dépendance directe entre les certains des bits du chiffré et du clair...

Faut aussi dire que pour 4 caractères à
256 possibilités chacun cela fait plus de 4 milliards de possibilités pour
une clef de 4 caractères. Donc, 4 milliards moins 640 clefs différentes
pour un même clair, les 640 ne sont qu'une poussière à côté.

Ce n'est pas tellement la quantité qui compte, c'est le temps qu'on met
à trouver une des clés. Quand je marche, je traverse quelques milliards
de nanomètres en quelques secondres. Pour moi, un milliard c'est une
seconde. Alors 4 milliards de clé, c'est 4 secondes.

Ces clés répondent au problème suivant :
M=[8;12;21]
C=[32;51;62]
Avec le procédé utilisant le xor.

Si nous nous sommes trompés, merci de vérifier les calculs suivants :
SAxor([1;2;3],[1;2;3;4])=[5;11;13]
SAxor([255;255;255],[255;255;255;255])=[2;2;2]
SAxor([0;0;0],[255;255;255;255])=[0;0;1]
SAxor([255;255;255],[0;0;0;0])=[254;254;255]
SAxor([8;12;21],[1;5;68;225])=[32;51;62]

Ces 5 exemples sont corrects. Et les clefs de votre autre message antérieur
étaient bonnes aussi même si aucune ne correspondait avec ma clef.

Il n'est pas utile (vu les specs actuelles) de trouver _la_ clé. Tout
simplement parce que c'est impossible. Par contre, on peut trouver plein
de clés qui ouvrent aussi la porte. La tienne est dans le lot, mais on ne
peut pas savoir laquelle c'est et on s'en moque.

En effet, toutes les clés trouvées sont équivalentes pour l'algorithme.

Je voulais dire qu'à partir d'un chiffré on peut désigner n'importe
quelle clé ou clair pour ensuite retrouver le morceau manquant.

Quel morceau manquant?

Soit un chiffré. On désigne arbitrairement un clair. On pourra toujours
trouver une clé qui établisse la liaison entre les deux. Et pareil si on
choisit une clé arbitraire.

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

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... ;-)

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à ?

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.

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...

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.

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.

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

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 ;-)

D'ailleurs, si vous vouliez bien présenter une spécification complète de
votre algo... c'est difficile de faire tomber une partie de votre algo, et
de vous entendre répondre "mais il n'y a pas que cela", sans savoir ce
qu'est le reste... Si vous ne donnez pas le reste, autant ne rien faire.

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
:-)

Pas d'autres tentatives sans spécifications.

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.

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.

Je pense qu'en doublant le nombre de caractères dans la clef cela
diminuerait de moitié le nombre de clef possible.

Oh que non ! Je causerait bien de projection d'espaces vectoriels mais je
sens que la journée risque d'être rude. En "français", donc :-)

Soit M un clair, de taille/dimension 3.
Soit C le chiffré, de taille/dimension 3.

M et C sont liés algorithmiquement par plein de clés (640 par exemple
pour nos clairs et chiffrés particuliers). Le couple (M,C) désigne des
bouts (partitions, relation d'équivalence...) de l'ensemble des clés. Le
nombre de possibilité de (M,C) est fixe quelque soit l'espace des clés.
Agrandir l'espace des clé ne va qu'aggrandir les classes de clés,
c'est-à-dire les groupes de clés équivalentes.

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

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

Salut !

Désolé, je vais peut-être être méchant sur ce coup là...

Je dis que vous avez une CERTAINE compétence comme beaucoup ont, y
compris moi. Chacun à son propre niveau. Les uns plus que d'autres.
De plus, je ne néglige pas tout ce que je lis, et je ne met pas pour autant
TOUTES ma confiances dans les scientifiques. Prenez par exemple certaines
'lois de la physique' concernant le mouvement perpétuel, et bien d'autres.
Des professeurs universitaires enseignent que le mouvement perpétuel est
impossible et pourtant on a la preuve du contraire: sans parler de
l'invention en France; regardons la terre qui fait le tour du soleil.

Bah c'est pas un mouvement perpétuel puisque la Terre se rapproche
lentement du Soleil et qu'elle ralentit un peu aussi (les deux doivent
d'ailleurs être liés). C'est bien dû à une perte d'énergie.
Ensuite, le mouvement perpétuel n'existe pas dans notre environnement
car les pertes d'énergie provoquent forcément une variation de ce
mouvement et il s'arrêtera un jour ou l'autre.

Mais, concernant le 'hachage' ou 'hash', j'ai déjà parlé du code
d'identification généré par la phrase de passe par un certain calcul.
N'est-ce pas d'une certaine façon en rapport avec le hachage? Puisque c'est
de façon non inversible. Si je prend le MD5, il peut pourtant produire des
collisions et n'est donc plus considéré comme sûr. Voir à
http://fr.wikipedia.org/wiki/Fonction_de_hash à la section 'Fonction de hash
cryptographique'.

On peut produire des collisions avec tous les algos de hachage. Là où ça
devient intéressant, c'est quand on cherche à savoir à quel rythme on
peut les produire. Avec MD5 c'est extrêmement compliqué et long si on ne
maîtrise rien des données à la base du hash.
SHA-1 est tellement coriace qu'il va probablement servir encore de très
longues années.
Mais si vous pondez un hashage quelconque, rien ne dit qu'il sera
suffisamment solide pour être utilisé, lui...

Tous ceci pour vous dire que vous pouvez employer un langage plus simple
lorsque vous pensez que moi ou d'autres ne sommes pas à la hauteur de vos
compétences.

Le problème n'est pas là. Ce n'est pas qu'une question de langage. Vous
n'avez manifestement pas les compétences suffisantes pour que la
discussion soit claire et sans ambiguité, ce qui la rend complexe pour
tout le monde.
Ce n'est pas forcément un reproche, mais un moyen de vous poussez à
ouvrir un bouquin de cryptographie pour améliorer votre niveau, et
permettre à tout le monde de se comprendre beaucoup plus facilement.
Certaines (longues) suites de messages n'ont pour seul but que de
répéter plusieurs fois la même chose sous diverses formes jusqu'à ce que
tout le monde soit d'accord. C'est assez pénible.

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.

Moi aussi je mets du temps pour expliquer à tous ceux qui nous lisent et
ça instruit du même coup quelques personnes sûrement. J'ai démarré un algo
publiquement ici afin que les gens puissent le développer aussi (s'ils le
désirent) et non moi seul, et cela afin que nous puissions tirer
instructions, les uns des autres, donnée dans ce fil de discussion.

Euh... mine de rien, on t'aide à développer un algo pour une application
commerciale... Alors si tu arrives à la vendre un jour, on partage ? Non
? Bon, ben d'accord, on se comprend...

Bon finalement j'ai pas été méchant... trop fatiguant, faut croire...
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/

Mister Jack wrote:

[...] 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.

Attention, quand on agresse l'OTP d'une telle manière, on finit par se
faire plonquer ;-)

cf : http://www.google.fr/groups?selm=m3wua4ouho.fsf%40passoire.afraid.org

Bon calculs!

Le simple algo xor (SAX, pour faire court) est exhaustivement cassé.
Toutes les clés sont disponibles en un laps de temps court.

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.

L'algo est récursif. Résoudre le problème pour une clé de N octets
revient à résoudre le problème pour N-1 octets. Le temps de traitement
de N-1 octets est négligeable par rapport au temps de N octets. Marrant.

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...

Un cassage en temps constant sur la longueur de la clé, le rêve. En fait
c'est faux : plus il y a de clé équivalentes, plus il met de temps à
les... parcourir :-p



Voici un challenge, histoire de...

Le clair : [254;178;245]
Le chiffré : [ 80; 91;223]

La première clé est : [ 0 80 10 78 ]
Quelques intermédiaires : [ 10 214 148 174 ]
[ 22 122 122 174 ]
La dernière est : [ 254 254 254 174 ]

Le temps de calcul est de 1 heure 9 minutes 22 secondes !
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 :-)

Au suivant !

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

Salut !

Mister Jack wrote:

[...] 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.

Attention, quand on agresse l'OTP d'une telle manière, on finit par se
faire plonquer ;-)

Oui, évidemment, il faut tenir compte du problème temporel.

Malheureusement l'algo de R.H n'a pas le même rôle à jouer qu'OTP comme
il le dit lui-même ; sinon autant utiliser OTP :p
Ce que je ne comprend pas, c'est qu'il veut générer une clé de session
plus longue que le message (!) et que c'est elle que l'utilisateur
devrait retenir... dans ce cas là on utilise OTP et on ne cherche plus à
innover par n'importe quel moyen avec des algos plus ou moins faibles...

Mais merci de m'avoir remis dans le droit chemin ;-)
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du Tsunami : http://www.croix-rouge.fr/