Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Sécurité Sécurité Cryptologie Simple algo: 3e étape - attaque à clair ou chiffré connu

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

81 réponses
Avatar
Raymond H.
Bonjour,
avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.
41 105 71 63 =k
51 52 53 =m
249 281 250 =c

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

Donc,
1- la clef n'est pas trouvable par inversion de l'algo seul ou d'un calcul
quelconque (sans parler d'attaque à clair ou chiffré connu...)
2- le clair n'est pas trouvable par inversion de l'algo seul ou d'un calcul
quelconque (sans parler d'attaque à clair ou chiffré connu...)

J'ajoute donc maintenant un Xor et une addition au calcul de l'algo
ci-avant afin de tenter d'empêcher de trouver la clef ou le clair par le
moyen d'une attaque à clair ou chiffré connu. Voici le nouvel algo:

41 105 71 63 =k
51 52 53 =m
185 199 12 =c

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 fait donc:
c1:
41 + 105 + 51 + 52 = 249
249 xor 105 = 144
144 + 41 = 185
185 Mod 256 = 185 = c1


c2:
105 + 71 + 52 + 53 = 281
281 xor 71 = 350
350 + 105 = 455
455 Mod 256 = 199 = c2

c3:
71 + 63 + 53 + 63 = 250
250 xor 63 = 197
197 + 71 = 268
268 Mod 256 = 12 = c3

Ici on suppose encore qu'on ne fait pas de boucle avec la clef et
qu'elle
serait en réalité une sous chaîne générée par la clef et qu'elle serait de
la même longueur que le clair plus un caractère. Voilà pour cette tentative
d'empêcher de trouver la clef par une attaque à
clair ou chiffré connu.

J'attends donc vos suggestions, et vous donne un test pour trouver soit
la clef (k) ou le clair (2m). Voici donc le clair et son chiffré plus un
autre chiffré crypté avec la même clef que le clair/chiffré. Je n'ai pas eu
besoin d'utiliser le modulo dans 1c ni 2c puisque aucune des valeurs des
deux chiffrés n'ont dépassées 255.

? ? ? ? = k
8 12 21 = 1m
32 51 62 = 1c

? ? ? ? = k
? ? ? = 2m
53 22 44 = 2c

Bon calculs!
Raymond H.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Mister Jack
Salut !

Bonjour,
avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.


Ca c'est vous qui le dîtes. Vous vous basez sur une constatation
mathématique simple. Vous oubliez qu'il n'y a aps que ça qui entre dans
l'équation.

J'ajoute donc maintenant un Xor et une addition au calcul de l'algo
ci-avant afin de tenter d'empêcher de trouver la clef ou le clair par le
moyen d'une attaque à clair ou chiffré connu. Voici le nouvel algo:


<couic>
Vous avez simplement ajouté un (XOR k) à à un algo très faible. Autant
faire simplement un XOR sur le message. C'est plus simple, plus rapide,
et c'est aussi peu solide. (length(clé) << length(message)).

J'attends donc vos suggestions, et vous donne un test pour trouver soit
la clef (k) ou le clair (2m).


Ce groupe vous a déjà montré à plusieurs reprises les faiblesses de
votre algo. Cessez de faire des retouches homéopathiques dessus !
Mettez-vous réellement à la crypto, prenez des bouquins (des gens
compétents ici pourront vous en conseiller), lisez les publications, les
articles, et apprenez !

Citation de Guillermito : "Et puis on a une certaine habitude dans ce
groupe. Vous allez faire une nouvelle version avec une permutation de
plus, et revenir lancer un défi. On n'en finit jamais. Ce qu'il faut,
c'est que vous compreniez *pourquoi* votre algorithme est extrèmement
faible et cassable. Sinon, ça ne sert à rien."

Citation de AMcD : "Laisse-tomber. Le gars va modifier son truc sans
cesse et comme personne n'aura le temps ou l'envie de le lui démonter,
ou bien se lassera, il répondra "ben vas-y, casse-le mon algo ! J'ai
proposé de le casser personne n'y est arrivé, donc, c'est le meilleur,
incassable, blabla.". Tu sais très bien comment ça va finir."

Voyez vous même : c'est exactement ce qu'il se passe. La version
actuelle de votre logiciel est attaquable à clair à tous les niveaux, et
une attaque directe est envisageable si on veut s'en donner la peine.
Donc vous faites une petite modif et relancez le défi. Je trouve que ce
groupe a assez donné pour vous aider, alors écoutez-le, et cherchez une
autre voie.
Parce que, finalement, votre voie "innovante" ne l'est pas : c'est ce
que ressortent tout les néophytes en crypto qui pensent pouvoir créer un
programme solide à partir de rien.

Je ne vous attaque pas mais souhaiterais que vous n'écoutiez pas
seulement ce groupe quand votre algo est mis à mal. Merci.

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

Avatar
Raymond H.
"Mister Jack" a écrit dans le message de news:
41e11049$0$11972$
Bonjour,



Qu'est-ce qui ne va pas 'Mister Jack'? Nos échanges étaient pourtant ok
entre nous par courriel.

Je pense que vous n'avez pas compris le but des messages 'Simple algo' et
'Simple algo: 3e étape...' dans ce forum. Le but est d'essayer de
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 logiciel mais
d'un algo à construire qui pourrait le remplacer ou sur lequel je pourrais
m'inspirer pour la version 3. Donc, il est question ici d'une construction
étape par étape d'un algo simple. Ce n'est pas pour vous mettre au défit
dans un esprit de mépris mais pour qu'ensemble on puisse voir qu'elle sont
les avantages et les désavantages de chacune des étapes de l'algo. Et si
j'ai mis un test c'est pour voir si l'étape présente tient la route ou non;
c'est une façon de s'instruire aussi (je ne parle pas que de moi mais de
tous ceux à qui ça intéresse sur ce groupe; ceux à qui ça n'intéresse pas
ils ne sont pas obligé de participer ni de lire). Tous les gens ne sont pas
nécessairement de votre niveau et ce groupe n'est pas limité non plus au
plus connaissant. Lisez le fil de discussion sur l'étape 1 et 2 du 'Simple
algo' et vous devriez voir l'esprit dans lequel le développement et les
commentaires du 'Simple algo' sont amenés.


Salut !

avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.


Ca c'est vous qui le dîtes. Vous vous basez sur une constatation
mathématique simple. Vous oubliez qu'il n'y a aps que ça qui entre dans
l'équation.

Vous semblez vous tromper ici (peut-être n'avez-vous pas suivi tout le

fil de discussion sur le sujet 'Simple algo' précédent). Ici c'est la
suite, car je débute l'étape 3, et l'affirmation précédente ne concerne que
les étapes 1 et 2 du 'Simple algo...'.

Je ne suis pas le seul à dire qu'il n'est pas possible à partir de
l'algo SEULEMENT de trouver la clef ou le clair (ici je parle des étape 1 et
2 et non pas de l'étape 3 actuelle). Christophe HENRY, qui a donné des
explications poussées, le dit aussi et je me base aussi sur lui et le reste
et c'est ce que signifie le mot 'DONC' dans mon affirmation précédente: une
conclusion.

Mais si vous n'êtes pas d'accord avec le fait qu'il est impossible (à la
1re et la 2e étape) de trouver le clair (conclusion de la 1re étape) et la
clef (conclusion de 2e étape) seulement à partir de l'algo lui-même (ou d'un
autre calcul) et cela sans tenir compte des attaques à clair ou chiffré
connu alors vous pouvez quand même le démontrer et nous instruire, car c'est
le but du fil de cette discussion. Mon but n'est donc pas de mépriser les
gens en les attaquant, ni ignorer leurs commentaires.


J'ajoute donc maintenant un Xor et une addition au calcul de l'algo
ci-avant afin de tenter d'empêcher de trouver la clef ou le clair par le
moyen d'une attaque à clair ou chiffré connu. Voici le nouvel algo:


<couic>
Vous avez simplement ajouté un (XOR k) à à un algo très faible. Autant
faire simplement un XOR sur le message.


Avec seulement un XOR on peut faire l'inverse pour trouver la clef et
ainsi utiliser la clef pour déchiffrer tout le message. Il faudrait
expliquer le pourquoi un XOR seulement serait pareille et pourquoi l'algo
est très faible dans ses 2 premières étapes.

C'est plus simple, plus rapide, et c'est aussi peu solide. (length(clé) <<
length(message)).



Je demanderais qu'à vous croire. Par la lecture du fil dans la
conclusion de l'étape 2 on voit qu'il est sous-entendu que la longueur de la
clef est de la même longueur que le clair plus un caractère et qu'elle
remplace une chaîne générée par la clef.



J'attends donc vos suggestions, et vous donne un test pour trouver
soit la clef (k) ou le clair (2m).


Ce groupe vous a déjà montré à plusieurs reprises les faiblesses de votre
algo.


Faut pas mélanger les choses. Ici, on parle du 'Simple algo'.

Cessez de faire des retouches homéopathiques dessus !
Mettez-vous réellement à la crypto, prenez des bouquins (des gens
compétents ici pourront vous en conseiller), lisez les publications, les
articles, et apprenez !

Citation de Guillermito : "Et puis on a une certaine habitude dans ce
groupe. Vous allez faire une nouvelle version avec une permutation de
plus, et revenir lancer un défi. On n'en finit jamais. Ce qu'il faut,
c'est que vous compreniez *pourquoi* votre algorithme est extrèmement
faible et cassable. Sinon, ça ne sert à rien."


Hors sujet ici.


Citation de AMcD : "Laisse-tomber. Le gars va modifier son truc sans cesse
et comme personne n'aura le temps ou l'envie de le lui démonter, ou bien
se lassera, il répondra "ben vas-y, casse-le mon algo ! J'ai proposé de
le casser personne n'y est arrivé, donc, c'est le meilleur, incassable,
blabla.". Tu sais très bien comment ça va finir."


Hors contexte ici aussi, puisque AMcD a dit ça dans un autre sujet que celui
du 'Simple algo...'.


Voyez vous même : c'est exactement ce qu'il se passe. La version actuelle
de votre logiciel est attaquable à clair à tous les niveaux, et une
attaque directe est envisageable si on veut s'en donner la peine. Donc
vous faites une petite modif et relancez le défi.


Faudrait lire d'un autre oeil, car vous n'avez pas saisi le pourquoi du fil
ici. Il est question des différentes étapes du 'Simple algo'.

Je trouve que ce groupe a assez donné pour vous aider,


Faudrait parler pour vous-même et ne pas décider pour les autres; tous
n'ont pas la même opinion que vous et certains se font un plaisir de suivre
le fil ou d'y participer. Aussi, quelques personnes ont déjà données leur
témoignage disant que le fil sur mon logiciel leur a aidé à comprendre des
choses et qu'ils ne sont pas contre le fait que ce fil ait lieu. C'est
écrit dans ce groupe, il faut juste lire.


alors écoutez-le, et cherchez une autre voie.


Vous semblez parler comme si le groupe vous appartenait. Je trouve ça
regrettable et je dirais comme il a déjà été répondu par une personne à une
autre qui disait ne pas aimer le sujet; elle disait :
"Ça ne me déplait pas tant que ça. Ces enfilades m'ont permis de lire....
Pour un néophyte comme moi, ça a un côté instructif... . Sinon, il suffit
d'ignorer les fils en question...".
Aussi:
">Pour un néophyte comme moi, ça a un côté instructif.
Exact pour moi aussi".

Vous pouvez lire ça dans 'Pollution dans fr.misc.cryptologie'.

Parce que, finalement, votre voie "innovante" ne l'est pas : c'est ce que
ressortent tout les néophytes en crypto qui pensent pouvoir créer un
programme solide à partir de rien.

Je ne vous attaque pas mais souhaiterais que vous n'écoutiez pas seulement
ce groupe quand votre algo est mis à mal. Merci.

Amicalement,


Si c'est amicalement alors tant mieux, car votre intervention me laissait
penser autrement.
Bonne journée :-)
r.h.


Avatar
case
Raymond H. wrote:
Bonjour,
avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.


Je reprends pratiquement ou nous en etions restes dans notre
conversation via mail prive a la fin de l'annee derrniere, mais cette
fois je prefere m'exprimer sous le controle des gens d'ici, pour
beaucoup bien plus savant que moi:

Il me semble que vous faites fausse route en voulant concevoir un algo
de crypto de facon "incrementale".

En procedant de cette facon vous ne parviendrez qu'a empiller
successivement un multitude de morceaux chaqu'un resistant a une
attaque et vulnerable a une multitude d'autres.

Ce serait comme fabriquer une chaine avec des maillons en cartons.
Quel que soit la longueur de la chaine ou la resistance d'un maillon
donne, la resistance globale de la chaine sera celle du maillon le plus
faible.

Il me semble qu'en cryptographie, il faut prealablement identifier les
attaques possibles, concevoir theoriquement les contres-mesures
efficaces contre ces attaques, enfin trouver un algo qui synthetise
toutes ces contre-mesures en un seul "bloc", suffisement coherent.

Je ne suis pas de la partie, et je me doute que cette description doit
sembler bien naive a beaucoup, mais elle me semble tout de meme plus
saine que "j'implemente un algo resistant a l'attaque A, je lui
superpose un algo resistant a l'attaque B, etc...".

Au risque de me repeter, je ne puis que vous conseiller d'etudier ne
serait-ce que le DES, voir et comprendre comment il est concu...

--
case Pratiquez-vous la zone danse? O/N
Frequentez-vous des embroches? O/N
Etes-vous souvent en interface? O/N
Etes-vous cable? O/N

Avatar
Christophe HENRY

avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.
...
Donc,
1- la clef n'est pas trouvable par inversion de l'algo seul ou d'un calcul
quelconque (sans parler d'attaque à clair ou chiffré connu...)
2- le clair n'est pas trouvable par inversion de l'algo seul ou d'un calcul
quelconque (sans parler d'attaque à clair ou chiffré connu...)


Je confirme. Aux conditions draconiennes pour la clé. Ce qui rend
l'algorithme inutilisable en pratique. Se reporter au cas d'un algorithme
symétrique vulnérable aux attaques à clairs connus.


J'ajoute donc maintenant un Xor et une addition au calcul de l'algo
ci-avant afin de tenter d'empêcher de trouver la clef ou le clair par le
moyen d'une attaque à clair ou chiffré connu. Voici le nouvel algo:

41 105 71 63 =k
51 52 53 =m
185 199 12 =c

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)


Celui-là m'a donné du fil à retordre. Nous arrivons ici aux limites de
ma compétence. Cela ne veut pas dire que le simple algo est
"invulnérable". Simplement mes petites capacités ne suffisent plus à
trouver d'attaque mathématisable. Je manque de connaissance pour ce
faire.

En particulier, l'examen des valeurs délivrés par des chiffrements de
clairs ou de clés dont la valeur est proche révèle complétement la
structure du chiffrement. C'est l'étude qu'avait fait AMcD avec
l'histoire du dessin faisant apparaître un X :
<41b3d7ac$0$17528$


La cryptologie n'est qu'un amusement pour moi. Il doit y avoir autant de
différences entre un expert patenté et moi, qu'entre moi et toi. Mesure
un peu la difficulté :-o


Ici on suppose encore qu'on ne fait pas de boucle avec la clef et
qu'elle
serait en réalité une sous chaîne générée par la clef et qu'elle serait de
la même longueur que le clair plus un caractère.


C'est une erreur de faire cela. L'entropie, le choix des clés, ne sera
pas plus élevé pour autant. Lorsque tu as ajouté le k4, j'ai au
contraire pu trouver plus de clés que nécessaire.


J'attends donc vos suggestions, et vous donne un test pour trouver soit
la clef (k) ou le clair (2m). Voici donc le clair et son chiffré plus un
autre chiffré crypté avec la même clef que le clair/chiffré. Je n'ai pas eu
besoin d'utiliser le modulo dans 1c ni 2c puisque aucune des valeurs des
deux chiffrés n'ont dépassées 255.

? ? ? ? = 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] ?

Il suffit de fixer une ou deux contraintes, et le reste vient tout seul...


? ? ? ? = k
? ? ? = 2m
53 22 44 = 2c


Subtil, celui-là :-o Ca n'a pas de sens. Il existe en effet un très
grand nombre de "k" possibles pour le premier problème.
Du coup, ton "k" peut ne pas correspondre au mien, et ton "2m" non plus.


D'une manière générale, tu devrais renoncer aux points suivants :
- mixer les m1, m2,... parce que ça ne rend _pas_ l'algo plus fort.
- mixer les k1, k2 pour la même raison que précédemment.
- utiliser une clé plus longue que le clair, sinon il y en plus que 1.

Au final, tu peux rester avec des lignes du style :
c1 = ((m1 + k1) xor k2) + k1 [mod 256]
c2 = ((m2 + k2) xor k3) + k2 [mod 256]
c3 = ((m3 + k4) xor k4) + k3 [mod 256]

L'algo sera plus simple à lire et ni plus faible, ni plus fort.


Je reste persuadé que la cryptanalyse est un métier et une histoire,
aussi. Toujours disposé à t'aider, je t'invite très vivement à :
- te documenter sur cette discipline.
- revoir tes 'simple algo' à la lumière de l'histoire de la
cryptographie.
- cesser de commercialiser un outil de chiffrement faible.

Relis les remarques de Mister Jack et les autres (dont j'ai toujours
plaisir à lire les interventions), avec lesquels je suis *totalement*
d'accord.
Si j'ai pu malmener ton procédé de calcul, les autres pourront faire
bien plus.

Je ne compte pas trop continuer cette joute intellectuelle. Ca m'a bien
fait réviser mes mathématiques, et ça m'a bien diverti. Maintenant que
tu lis quelqu'un que tu sais capable de démonter tes algorithmes, relis
bien les remarques des autres concernant la résistance de ton algorithme.
Je les approuve complètement. Pas un peu. Non : totalement.

Les raisonnements que j'ai présenté sont le minimum de ce qu'un
cryptologue devrait savoir. Et ceux dont tu pourrais douter doivent en
savoir bien plus que moi. Reconsidère leurs conseils.


Aux autres lecteurs du forum :

Si le côté cryptologie est entendu, j'ai un problème concernant
l'aspect mathématique du problème. Je suis bloqué par ceci :

Soit K un entier naturel, la clé.
Soient a et b deux entiers naturels non nuls, servant de représentation
de l'algorithme.
Soit m le texte clair, un entier naturel.
Soit c le texte chiffré, un entier naturel.

La cryptanalyse du 'simple algo' se résume en le problème suivant :
c = ( (m+k) xor (a*k) ) + b*k [mod 256]

Avec un xor seul, je sais résoudre.
Avec un modulo seul aussi.
Avec les deux, ça va dès lors que je peux fixer a*k ou b*k.

Avez-vous des idées de pistes à parcourir ?

--
Christophe HENRY
(sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A

Avatar
Raymond H.
"case" a écrit dans le message de news:
41e18eb8$0$5708$
Raymond H. wrote:
Bonjour,
avec l'algo suivant il n'est donc pas possible, à partir de l'algo
seulement, de trouver la clef ni le clair.


Je reprends pratiquement ou nous en etions restes dans notre
conversation via mail prive a la fin de l'annee derrniere, mais cette
fois je prefere m'exprimer sous le controle des gens d'ici, pour
beaucoup bien plus savant que moi:

Bonjour,

content de vous relire :-) Par courriel vous avez eu l'amabilité de me
faire une démonstration d'une attaque réussie via le clair et le chiffré
pour trouver la clef. Cette attaque réussissait à casser la clef du 'Simple
algo' de l'étape 1. Ce genre d'attaque n'était plus possible à l'étape 2.
Mais, Mister Jack a aussi eu l'amabilité de me donner une démonstration
d'une attaque réussie via un clair/chiffré plus un autre chiffré crypté avec
la même clef, et il a réussi à prouver que le clair de l'étape 2 était
trouvable.
Ici, ne n'oublie sûrement pas les nombreuses interventions constructives
de Christophe HENRY démontrant aussi ses dires en en donnant des preuves par
plusieurs calculs intéressants.
Mais faut dire aussi que les étapes 1 et 2 étaient plutôt pour empêcher
des calculs inverses de l'algo ou autre (sans attaque à clair ou chiffré
connu). Mais quand même, tous vous avez démontrés que les étapes 1 et 2 ne
suffisaient pas.
Tenant compte de votre démonstration, de celles de Mister Jack et de
celles de Christophe HENRY, j'ai donc dû réfléchir pour empêcher ces deux
genres d'attaque tout en maintenant l'empêchement de l'inversion du calcul
algorithmique servant à trouver la clef ou le clair des étapes 1 et 2.
Ainsi, nous sommes à l'étape 3 pour vérifier l'empêchement de ces attaques à
clair ou chiffré connu.

Il me semble que vous faites fausse route en voulant concevoir un algo
de crypto de facon "incrementale".

En procedant de cette facon vous ne parviendrez qu'a empiller
successivement un multitude de morceaux chaqu'un resistant a une
attaque et vulnerable a une multitude d'autres.

Ce serait comme fabriquer une chaine avec des maillons en cartons.
Quel que soit la longueur de la chaine ou la resistance d'un maillon
donne, la resistance globale de la chaine sera celle du maillon le plus
faible.

Il me semble qu'en cryptographie, il faut prealablement identifier les
attaques possibles,


Oui. À la page http://www.uqtr.ca/~delisle/Crypto/cryptanalyse/ il y en a
quelques unes.

concevoir theoriquement les contres-mesures
efficaces contre ces attaques, enfin trouver un algo qui synthetise
toutes ces contre-mesures en un seul "bloc", suffisement coherent.


C'est ce que je tente de découvrir ici. Je crois que cela est possible via
un algo très simple.


Je ne suis pas de la partie, et je me doute que cette description doit
sembler bien naive a beaucoup, mais elle me semble tout de meme plus
saine que "j'implemente un algo resistant a l'attaque A, je lui
superpose un algo resistant a l'attaque B, etc...".


Si A et B sont de trop, peut-être qu'un C (à partir de A et B) pourrait
remplacer A et B pour faire plus simple.


Au risque de me repeter, je ne puis que vous conseiller d'etudier ne
serait-ce que le DES, voir et comprendre comment il est concu...



En parlant du DES, j'ai lu qu'il a été cassé en 1999 en 22 heures seulement.
Sûrement à cause de la limite de caractères de la clef.


Bonne journée
r.h.


Avatar
Sylvain

En parlant du DES, j'ai lu qu'il a été cassé en 1999 en 22 heures seulement.
Sûrement à cause de la limite de caractères de la clef.



ce point et le critère: "ne pas avoir une clé courte par rapport au
clair" semble orienter votre élaboration actuelle vers une "clé longue"
("comparable à" ou "de même taille que" le clair), est-ce cela ?

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

Sylvain.

Avatar
case
Raymond H. wrote:

Au risque de me repeter, je ne puis que vous conseiller d'etudier ne
serait-ce que le DES, voir et comprendre comment il est concu...



En parlant du DES, j'ai lu qu'il a été cassé en 1999 en 22 heures seulement.
Sûrement à cause de la limite de caractères de la clef.


Oui, mais je ne vous conseillais pas de l'utiliser "tel quel", mais de
l'etudier, pour constater comment des gens voila 30 ans ont resolut les
problemes auquels vous vous attaquez aujourd'hui.

Et comme vous le faites remarquer, le DES n'a pas ete casse par une
faiblesse quelconque de l'algo lui meme mais par force brute, ce qui
montre que mis a part la longueur trop faible de la clef (ce qui
d'ailleurs a ete fait expres il me semble), il a plutot bien tenu
l'epreuve du temps.

--
case Pratiquez-vous la zone danse? O/N
Frequentez-vous des embroches? O/N
Etes-vous souvent en interface? O/N
Etes-vous cable? O/N


Avatar
Raymond H.
"case" a écrit dans le message de news:
41e1bf3f$0$6626$
Raymond H. wrote:

Au risque de me repeter, je ne puis que vous conseiller d'etudier ne
serait-ce que le DES, voir et comprendre comment il est concu...



En parlant du DES, j'ai lu qu'il a été cassé en 1999 en 22 heures
seulement. Sûrement à cause de la limite de caractères de la clef.


Oui, mais je ne vous conseillais pas de l'utiliser "tel quel",


C'est ce que j'avais compris :-)

mais de
l'etudier, pour constater comment des gens voila 30 ans ont resolut les
problemes auquels vous vous attaquez aujourd'hui.

Et comme vous le faites remarquer, le DES n'a pas ete casse par une
faiblesse quelconque de l'algo lui meme mais par force brute, ce qui
montre que mis a part la longueur trop faible de la clef (ce qui
d'ailleurs a ete fait expres il me semble), il a plutot bien tenu
l'epreuve du temps.
En effet.

Bonne soirée
r.h.



Avatar
Raymond H.
"Sylvain" a écrit dans le message de news:
41e1bd85$0$8047$

En parlant du DES, j'ai lu qu'il a été cassé en 1999 en 22 heures
seulement. Sûrement à cause de la limite de caractères de la clef.



ce point et le critère: "ne pas avoir une clé courte par rapport au clair"
semble orienter votre élaboration actuelle vers une "clé longue"
("comparable à" ou "de même taille que" le clair), est-ce cela ?

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



Bonsoir,

je ne sais pas vraiment quelle technique utiliser encore car j'ai
plusieurs idées. Mais la plus probable est que le programme générerait une
chaîne (sous-clef) unique à chaque cryptage. La clef que l'utilisateur
écrirait ne serait pas utilisée pour le cryptage du clair mais seulement
crypter cette clef modifiée et pour dire, lors du décryptage, si c'est bien
cette clef qui a été écrite par l'utilisateur.



1- L'utilisateur écrit sa clef. Cette clef est transformée (soit par des
xor ou autres procédés, main non réversible). Donc, cette clef n'est pas
utilisée pour crypter le clair mais seulement pour crypter la modification
de cette clef et la chaîne générée par cette clef (chaîne qui sert à crypter
le clair). Cette clef serait utilisée aussi pour reconnaître, lors du
décryptage, si c'est cette même clef qui a été écrite par l'utilisateur pour
procéder au cryptage. Elle ne servirait à rien d'autre.



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.

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

La chaîne serait rallongée par calcul tant et aussi longtemps qu'il y a
des caractères à crypter, mais ce serait seulement la portion générée au
début qui serait cryptée avec le clair. Le calcul effectué pour rallonger
la chaîne ne reproduirait pas les mêmes valeurs et cela dans un ordre non
prévisible. 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.

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



2- Au décryptage, l'utilisateur doit écrire la même clef. La clef décrypte
la clef modifiée (identificateur de la clef) et la chaîne, et si la clef
correspond avec celle modifiée (identificateur de la clef) alors le logiciel
décrypte le chiffré à partir de la chaîne qui vient d'être décryptée par la
clef.



Je dois réfléchir sur la façon la meilleure pour rallonger la chaîne
générée au départ par le logiciel. Car il faut que cette chaîne soit
constituée de caractères non prévisibles.


a+
r.h.


Avatar
Christophe HENRY

"Sylvain" a écrit dans le message de news:
41e1bd85$0$8047$

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


je ne sais pas vraiment quelle technique utiliser encore car j'ai
plusieurs idées. Mais la plus probable est que le programme générerait une
chaîne (sous-clef) unique à chaque cryptage. La clef que l'utilisateur
écrirait ne serait pas utilisée pour le cryptage du clair mais seulement
crypter cette clef modifiée et pour dire, lors du décryptage, si c'est bien
cette clef qui a été écrite par l'utilisateur.


Tu m'as dit à quelques reprises que ton formalisme mathématique datait
un poil. Ceci-dit, tu sembles bien maîtriser le français ; au sens où
tes écris seraient durs à lire si tu écrivais en style sms.
Notre belle langue est cependant insufisante dans certains domaines, c'est
pourquoi les ordinateurs, les programmeurs, les cartes réseaux, moniteurs
et claviers dialoguent chacun dans une langue adaptée.

Il devrait en être de même ici afin :
- d'enlever l'ambiguité d'interprétation des textes lus.
- d'exprimer avec plus de précisions les procédés.

Pour commencer, "chiffrer"/"déchiffrer" sont les termes consacrés. Le
cryptage concerne plutôt l'acte de cacher, obfusquer. Si tu me réponds
"chacun utilise les mots qu'il veut", alors je remplacerais tous les
verbes par "schtroumpf" ;-)


1- L'utilisateur écrit sa clef. Cette clef est transformée (soit par des
xor ou autres procédés, main non réversible). Donc, cette clef n'est pas
utilisée pour crypter le clair mais seulement pour crypter la modification
de cette clef et la chaîne générée par cette clef (chaîne qui sert à crypter
le clair). Cette clef serait utilisée aussi pour reconnaître, lors du
décryptage, si c'est cette même clef qui a été écrite par l'utilisateur pour
procéder au cryptage. Elle ne servirait à rien d'autre.


La clé dont tu parles pour chiffrer le message s'appelle une "clé de
session". La clé dont tu parles pour l'utilisateur, qui doit se
mémoriser facilement, s'appelle une "phrase de passe".


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... Pour nous, l'essentiel est que les
éléments pour le chiffrement sont disponibles :
- phrase de passe de l'utilisateur
- tous événements (clics, par exemple) sont supposés acquis.

Bref : allons aux faits.


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é"

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



La chaîne serait rallongée par calcul tant et aussi longtemps qu'il y a
des caractères à crypter, mais ce serait seulement la portion générée au
début qui serait cryptée avec le clair.


"au début" ?


Le calcul effectué pour rallonger
la chaîne ne reproduirait pas les mêmes valeurs et cela dans un ordre non
prévisible.


Bref, c'est une "chaîne" aléatoire.


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.


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.


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.


Je dois réfléchir sur la façon la meilleure pour rallonger la chaîne
générée au départ par le logiciel. Car il faut que cette chaîne soit
constituée de caractères non prévisibles.


Avec ce que j'ai compris de ton idée, ça ne serait pas plus simple de
t'acharner au chiffrement de la clé de session ("clé modifiée", si j'ai
bien compris) tandis que le clair serait chiffré avec la clé de session
au moyen d'un simple xor ?

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 }

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.

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

--
Christophe HENRY
(sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A


1 2 3 4 5