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

Un petite question, car je vois que dans les bits vous y connaissez pas mal.
|||||| ||||

Dans ce domaine, la *taille* n'a pas d'importance.

Avec un clair ayant été chiffré avec une clef de 128 (mais seulement avec du
xor), serait-il possible de trouver m à partir de k et de c ?

J'ai l'impression qu'il te manque... disons... un _bit_ après le 128 ?

k= 123
mE6789

Donc, en ayant chiffré seulement de cette façon:
1 xor 4
2 xor 5
3 xor 6
1 xor 7
2 xor 8
3 xor 9

Vigenère.

Ou bien, trouver m à partir de k et de c, est-il indéchiffrable
seulement si la clef est unique et de la même longueur que le clair?

A quelques considérations près sur la qualité des clés utilisées, ce
cryptosystème connu sous le nom d'OTP est le seul mathématiquement
incassable. Le problème, c'est que c'est le seul algorithme efficace
pratiquement inutilisable.


--
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: cs9j3f$1tfs$1@biggoron.nerim.net...

Avec un clair ayant été chiffré avec une clef de 128 (mais seulement avec
du
xor), serait-il possible de trouver m à partir de k et de c ?

J'ai l'impression qu'il te manque... disons... un _bit_ après le 128 ?

Il est vrai que mon exemple ne correspond pas à 128 bits :-)

Disons que je repose la question. Selon l'exemple suivant, avec un
clair ayant été chiffré avec une clef d'une longueur moindre que le clair
(mais seulement avec du xor), serait-il possible de trouver m à partir de k
et de c ?


k= 123
mE6789

Donc, en ayant chiffré seulement de cette façon:
1 xor 4 = c1
2 xor 5 = c2
3 xor 6 = c3
1 xor 7 = c4
2 xor 8 = c5
3 xor 9 = c6

Vigenère.

Ou bien, trouver m à partir de k et de c, est-il indéchiffrable
seulement si la clef est unique et de la même longueur que le clair?

A quelques considérations près sur la qualité des clés utilisées, ce
cryptosystème connu sous le nom d'OTP est le seul mathématiquement
incassable.

k= 123456
mE6789
1 xor 4
2 xor 5
3 xor 6
4 xor 7
5 xor 8
6 xor 9

Il n'y aurait donc aucune différence si on fait des additions au lieu
des xor? N'est-ce pas? L'un ne serait pas plus efficace que l'autre?

1 + 4
2 + 5
3 + 6
4 + 7
5 + 8
6 + 9

Le problème, c'est que c'est le seul algorithme efficace
pratiquement inutilisable.

a+

r.h.

Il n'y aurait donc aucune différence si on fait des additions au lieu
des xor? N'est-ce pas? L'un ne serait pas plus efficace que l'autre?

Aucune différence. Ce sont des chiffres par substitution. Les tables de
subsitutions sont justes différentes.

D'ailleurs, au niveau du bit le xor est une addition modulo 2,

Dans le cas général, tu pourrais implémenter toute sorte de table de
conversion visant à chiffrer une donnée vers une autre, et elle fera
toujours partie de la même famille de fonctions : celles faisant
correpondre un clair de [0..255] vers un chiffré du même ensemble. Ces
applications sont automorphes, bijectives, inversibles et forment un
groupe. L'attribut de groupe signifie que la composée de deux
"chiffrages" est un chiffrage différent (en général) mais pas plus
résistant.

Vigenère, donc.

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

Que ce soit toi ou Mister Jack, je tiens à m'incliner devant autant
d'abnégation :-). Moi, il y a longtemps que j'ai lâché l'affaire...

Heu, il y a-t-il, sinon l'altruisme, une raison pour laquelle vous
persévérez dans votre mission d'expliquer au mouton égaré comment rejoindre
le troupeau de ceux qui réfléchissent avant de coder des algos de crypto :-)
?

--
AMcD®

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

Que ce soit toi ou Mister Jack, je tiens à m'incliner devant autant
d'abnégation :-). Moi, il y a longtemps que j'ai lâché l'affaire...

Que veux-tu, le talent ça ne s'invente pas ;-) Surtout qu'à défaut
d'avoir l'inspiration divine, on a ma motivation.

Heu, il y a-t-il, sinon l'altruisme, une raison pour laquelle vous
persévérez dans votre mission d'expliquer au mouton égaré comment rejoindre
le troupeau de ceux qui réfléchissent avant de coder des algos de crypto :-)

1/ le spam
J'ai très *mal* pris le post [SPA]initial pour Allcrypter :
indiquant que son logiciel était gratuit d'usage jusqu'en 2006 alors que
[GPG]gnupg et les algos (tant que les brevets logiciels ne seront pas
valables en Europe) sont dispo pour l'éternité.
C'est mon allergie pour la merdouille commerciale mal placée :-)

2/ le novice
Notre candidat cryptologue n'en est pas à son coup d'essai concernant le
développement de logiciels. Je considère cependant que son logiciel est
le logiciel de _trop_ et n'a pas sa place. Les logiciels de chiffrement,
je les considères libres (GPL, à code source ouvert), basés sur des
algos solides et conçus par une équipe compétente.

3/ le défi
Casser son algo de chiffrement est une chose. Parvenir à modifier quelque
chose dans l'esprit de son inventeur me paraît un défi intéressant,
presque aussi difficile que de concevoir le mouvement perpetuel.
Courrez-donc voir son site web pour vous faire une idée.

4/ le plaisir
J'aime bien discuter avec Raymond car j'y apprends la manière dont les
personnes non-cartésiennes raisonnent. Les échanges sont assez
enrichissants pour ma part. Et puis, quand on peut rendre service :-)
Je me met à sa place : je préfèrerais être roué, bafoué, trainé du
fait de la pauvreté patente de mon algorithme à la mors-moi-l'noeud
qu'être ignoré ou dénigré sans raison (de son point de vue, toujours)
apparante.

5/ les révisions
Ca me fait réviser ma programmation en C, la crypto, l'algèbre
linéaire, les (petites) techniques de cryptanalyse. C'est déjà bien.
Et en plus, j'en connais qui souffrent en lisant mes calculs ;`-]

Au plaisir :-)


== Références

[SPA] Spam original pour Allcrypter
Message-id: <aOgpd.55118$Le1.1159646@news20.bellglobal.com>
Disponible via : http://tinyurl.com/4cn3v
OU http://groups.google.fr/groups?as_umsgid=%3CaOgpd.55118%24
Le1.1159646@news20.bellglobal.com%3E&lr=&num0&hl=fr

[GPG] Logiciel Libre de chiffrement GnuPG
http://www.gnupg.org/(fr)/index.html


--
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: csave3$2jid$1@biggoron.nerim.net...

Il n'y aurait donc aucune différence si on fait des additions au lieu
des xor? N'est-ce pas? L'un ne serait pas plus efficace que l'autre?

Aucune différence. Ce sont des chiffres par substitution. Les tables de
subsitutions sont justes différentes.

D'ailleurs, au niveau du bit le xor est une addition modulo 2,

Dans ce cas ce ne serait pas vraiment sur l'algo de cryptage du clair
qu'il faudrait se pencher mais sur l'algo de prolongement d'une clef, pour
enfin de compte ne faire qu'un simple xor ou une simple addition avec k et
m. Puisque si cela ne correspond qu'à une clef unique n'ayant aucun cycle
d'itération ce pourrait être un algo incassable.

Le travail se ferait seulement sur la confidentialité de la clef finale
qui aurait été prolongée, autrement dit être incapable, tout en connaissant
l'algo de prolongement de la clef, de trouver en inversion la clef total de
session. Elle est donc créée d'une certaine longueur au début, puis
prolongée par un algo en se servant des données ascii du clair puis on fait
un simple xor de chaque caractère de m d'avec chaque caractère de la clef
prolongée. Le simple chiffrage du clair par un xor se ferait donc au fur et
à mesure que la clef se prolonge.

On garderait seulement les derniers caractères de la clef de session
(finale) afin de les taper pour exécuter le déchiffrage en sens inverse pour
restaurer le tout. On ne garde que la clef finale sinon on aurait un
chiffré du double du clair. On restaure donc la clef de session à partir de
la clef de session finale et du même coup on restaure le clair
graduellement. C'est selon l'idée de la 4e étape du simple algo à
l'exception que l'algo n'est pas concentré sur la transformation du clair
mais sur le prolongement de la clef de session afin d'avoir une clef à
caractères non prévisibles et non analysables pour empêcher des attaques.



Je vais donc me concentrer sur le moyen de prolonger une clef de session
jusqu'à la longueur du clair (cela en groupe de x caractères afin de n'avoir
que les derniers caractères au bout de la ligne: donc la clef de session
finale) de façon à ce qu'elle ne soit pas réversible sans connaître ses
derniers caractères (la clef de session finale).



k= 123 = clef de session initiale créée aléatoirement.

Je prolongerais ainsi à partir de la clef 123:

234 puis 345 puis 456... 56r puis 6rX Donc, jusqu'à ce que j'arrive vis à
vis du dernier caractère de la clef (en supposant qu'ils sont tous alignés).
Ici ma clef de session initiale est 234 et la clef de session finale est 6rX
qui servirait de mot (ou phrase) de passe. Car pour déchiffrer on part de
6rX pour restituer les caractères précédents de la clef de session jusqu'à
ce qu'on arrive à 234; et pendant ce processus de restauration via le
chiffré, le clair est restauré graduellement.

Donc on part avec la clef initiale 234 (créée aléatoirement), on crypte
le 1er caractère du clair à partir de 234, puis on prolonge la clef d'un
caractère (via l'algo, les derniers caractères de la clef et le clair) pour
donner 345 puis on crypte le prochain caractère du clair, et ainsi de suite
jusqu'à la fin du clair où on a la clef de session finale 6rX que l'on
conserve. Si on réussi à avoir une clef de session finale qui ne peut pas
être trouvé via l'algo et la fin du chiffré alors on aurait un algo
incassable à toute épreuve.


Bonne journée.

r.h.

Exemple:

k= 123 = clef de session initiale créée aléatoirement.

Je prolongerais ainsi à partir de la clef 123:

234 puis 345 puis 456... 56r puis 6rX Donc, jusqu'à ce que j'arrive vis à
vis du dernier caractère de la clef (en supposant qu'ils sont tous
alignés). Ici ma clef de session initiale est 234 et la clef de session
finale est 6rX qui servirait de mot (ou phrase) de passe. Car pour
déchiffrer on part de 6rX pour restituer les caractères précédents de la
clef de session jusqu'à ce qu'on arrive à 234; et pendant ce processus de
restauration via le chiffré, le clair est restauré graduellement.

Donc on part avec la clef initiale 234 (créée aléatoirement), on crypte
le 1er caractère du clair à partir de 234, puis on prolonge la clef d'un
caractère (via l'algo, les derniers caractères de la clef et le clair)
pour donner 345 puis on crypte le prochain caractère du clair, et ainsi de
suite jusqu'à la fin du clair où on a la clef de session finale 6rX que
l'on conserve. Si on réussi à avoir une clef de session finale qui ne
peut pas être trouvé via l'algo et la fin du chiffré alors on aurait un
algo incassable à toute épreuve.

Bien sûr aussi on peut permuter puis crypter la clef finale avec une

phrase de passe et faire cette opération une dizaine de fois, puis intégrer
cette clef finale (modifié et crypté) avec les données chiffrées. Ce serait
comme l'étape 4 du simple algo mais avec l'accent mis sur l'algo de la clef
au lieu du clair.

a+
Raymond H.

Salut !

Que ce soit toi ou Mister Jack, je tiens à m'incliner devant autant
d'abnégation :-). Moi, il y a longtemps que j'ai lâché l'affaire...

De l'abnégation ? Où ça ? ;-)

Heu, il y a-t-il, sinon l'altruisme, une raison pour laquelle vous
persévérez dans votre mission d'expliquer au mouton égaré comment rejoindre
le troupeau de ceux qui réfléchissent avant de coder des algos de crypto :-)
?

1/ détente
Bah oui, ça me détend de pouvoir faire mumuse avec son algo... Je
suppose que c'était pareil pour toi quand tu as jeté ton premier coup
d'oeil à AllCrypter : petite pause détente, non ?

2/ connerie
C'est méchant comme titre, mais je suis en manque d'inspiration. Pour
moi Allcrypter est l'exemple type du logiciel bidon qui ne sert à rien,
mais qui amène un risque pour ses utilisateurs mal informés du danger.
Y'a pas mort d'homme (pas encore [1]), mais quand même.

3/ souffrance
Je souffre en lisant les calculs de Christophe Henry, ça me rappelle que
si je garde pas le niveau partout, ça m'arrivera d'autant plus souvent.

4/ expérimentation
C'est quand même une expérience grandeur nature pour voir jusqu'où
l'esprit humain peut aller dans l'obstination. Faut en profiter pour
apprendre, ça n'arrive pas si souvent !

5/ pitié
Peut-être que quelqu'un aura pitié et m'expliquera toutes les arcanes de
GnuPG... :p

6/ people
Y'a tellement de monde qui s'est déplacé de fcsv jusqu'ici rien que pour
ça, qu'il fallait absolument que je vienne. La question c'était
"pourquoi je reste?" ? Ah... euh... Et bien...

7/ vitesse
Maniaque de la vitesse. Ou comment générer le + vite possible l'ensemble
des clés pouvant déchiffrer un message à Raymond. Powwwaaaaahhh !

Bon, j'arrête là, ma compil vient de se terminer. Sinon j'avais encore
des paragraphes sur 'challenge', 'dérouiller', 'pédagogie', 'brutalité',
'espoir', 'perdu', et bien d'autres.

[1] " Nous pouvons compter sur le fait que la diffusion de la
cryptographie va entrainer la perte de vies humaines. "
-- Robert Litt, procureur général pour le Département américain de la
Justice, Wired News, 8 juin 1998
http://www.fr.ixus.net/resume_messages.php?topic(01

Amicalement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Un don pour les victimes du manchot : http://www.microsoft.com

Dans ce cas ce ne serait pas vraiment sur l'algo de cryptage du clair
qu'il faudrait se pencher mais sur l'algo de prolongement d'une clef,

C'est une erreur. Je vais faire description imagée. Imagine que la clé
en question fasse deux caractères a et b, tu la prolonges de un
caractère au moyen de l'opération c=a+b.
La clé est ainsi (a,b,c). Question : (a,b,c) peut-il avoir toutes les
combinaisons possibles de a,b et c ? Il s'agit de l'une des conditions
draconiennes imposées à l'OTP auquel ton algo est, au mieux, équivalent.

La réponse est non : le nombre de combinaisons ne sera que de 256², le
troisième élément étant dépendant des deux autres. Or, la clé doit
remplir entièrement les possibilités de combinaisons, soit 256**3, pour
être correcte.

Le travail se ferait seulement sur la confidentialité de la clef
finale
qui aurait été prolongée,

Cette clé finale contient une partie du clair sous forme chiffrée. En
effet, elle dépend à la fois de la (vraie) clé initiale et du chiffré.
La "clé" finale n'est pas plus forte que la clé initiale. La
construction au fur et à mesure de cette clé finale est partie
intégrante de l'algorithme alors que clair et clé en sont des
paramètres.

...
On garderait seulement les derniers caractères de la clef de
session (finale)

Cela signifie qu'il suffit d'avoir les derniers caractères de la clé de
session, déchiffré ceux-ci si une phrase de passe est présente, pour
déchiffrer !

k= 123 = clef de session initiale créée aléatoirement.

Je prolongerais ainsi à partir de la clef 123:

234 puis 345 puis 456... 56r puis 6rX Donc, jusqu'à ce que j'arrive vis
à vis du dernier caractère de la clef (en supposant qu'ils sont tous
...

Livre les spécifications précises et complètes.


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

Dans ce cas ce ne serait pas vraiment sur l'algo de cryptage du clair
qu'il faudrait se pencher mais sur l'algo de prolongement d'une clef [..]

Le travail se ferait seulement sur la confidentialité de la clef finale
qui aurait été prolongée [..] On garderait seulement les derniers
caractères de la clef de session (finale) afin de les taper
pour exécuter le déchiffrage

ça devient confus pour l'utilisateur !!

un système "normal" voudrait qu'il ne mémorise et partage avec ses
correspondants qu'un ""message"" court (mais pas trop), ce que l'on
appelle "phrase de passe" ou "passphrase".

une telle petite phrase peut servir comme identifiant unique (comparé
bit à bit, tel un PIN code) pour débloquer l'usage de la (vrai) clé de
chiffrement, peut être utilisé comme graine ou partie d'un système de
construction ou de récupération de clé mais doit rester unique.

dans votre description, l'utilisateur devrait utiliser un code non
choisi pour réaliser le déchiffrement, ceci rends IMHO le système
inutilisable pour un "utilisateur normal" (car devant être transmit avec
chaque chiffré et étant -potentiellement- dur à retenir).

BTW, si la tentative est d'inventer une (vrai) clé à partir d'une
pasphrase et de qlq + et * (xor et shift), l'algo DES fait cela depuis
longtemps (la clé 8 ou 16 ne sert qu'à initialiser des SBox ou tables de
permutations).

si la tentative est de wrapper (traduction?) une clé longue par une
passphrase courte, les algos PBE (password based encryption) font
également cela très bien.

où vous situez-vous par rapport à ces références ?

intégrez-vous les exigences utilisateurs (ce qu'il devra mémoriser) dans
la conception de votre système ?

Sylvain.