Simple algo...

"Manu" <el@netcourrier.com> a écrit dans le message de news:
cqgk6d$9t6$1@reader1.imaginet.fr...

désolé je croyais avoir corrigé... j'ai juste réussi à passer pour un
idiot
:-)

Mais non, vous n'êtes pas idiot. Au moins vous avez participé avec une
bonne intention :-)
Bonne journée.
r.h.

ah ben si le grand raymond dit que vous ne l'êtes pas, vous ne l'êtes
vraiment pas !

parce que ce raymond est presque devenu notre consciense affective, il
sait toujours qui est gentil et qui est méchant - il sait même quand les
méchants qui disent du mal de ses codes deviennent des gentils quand le
Raymond n'arrive plus à masquer sa mauvaise foi; quel veinard ce AMcD!

c'est sur, une machine à distribuer les bons-points-raymond c'est pas
très utile dans le monde crypto; mais reconnaissons que nous pensions à
tort qu'elle ne servait à rien.

et puis surtout, Manu, vous avez réussi à faire générer à notre raymond
une phrase sans faute d'orthographe (déjà bien), sans faute de grammaire
(prodigieux) et pour tout dire compréhensible (le peinard!!!).

Sylvain.

PS (parce que ça flatte assez le coté caliméro de notre raymond):

"De plus, mon langage est simple pour celui qui prend
"la peine de prendre le temps de comprendre, du moins
"en très grande partie."

Peut s'écrire (et *doit* se poster): "mon langage est simple."

Merci d'intervenir, parfois, je me demande si je ne suis pas le seul à me
comprendre, vu les réponses qui me sont faites :-).

Je suis même sûr que le Père Noël lui-même te soutient. Son traineau
va trop vite pour le wifi, qui n'accorche pas le signal, ce qui explique
qu'il n'a pas répondu.

...
la réutilisation des clés (ou
mots de passe) va grandement faciliter les déchiffrements. S'il est
valable pour les transferts sensibles et ponctuels (et là, on xorise),
il est (me semble) inadapté à un usage régulier.

Sans compter qu'à la moindre intervention d'une multiplication dans sa
méthode (je prévois les éventuelles "améliorations"), ça va
collisionner de partout...

C'est vrai que pour le moment, ça ressemble à un automorphisme tout ce
qu'il y a de bijectif, si on suppose que les additions sont modulo 0xFF.
Avec des collisions, ça pourrait se transformer soit en fonction de
hachage, soit en multiplicateur de longueur de chiffré :-)

Pour étayer cette histoire de multiplication : le chiffrement de césar
s'appuie sur une addition. Avec une clé de 1, le "A" devient "B", le "B"
devient "C", jusqu'au "Z" qui devient "A". 26 lettres se font correspondre
26 lettres.

Avec une clé de 13, ca fait ça : Nirp har pyr qr gervmr, pn snvg pn


Si on s'amuse à multiplier par 2, par exemple :
le "A" codé '1' sera chiffré en '2' et sera donc lu comme "B".
Le "B" codé '2' sera chiffré en '4' et sera donc lu comme "D".

Deux problèmes se présentent :

1/ On perd des possibilités de codage : les 26 codes (1 code par lettre)
seront projetés dans un espace de 52 codes dont la moitié sera
inutilisée.

2/ Si on reste dans un espace d'arrivé de 26 valeurs, il va y avoir des
collisions dès qu'on passe les résultats au modulo. En voici une :
"N" codé '14' sera chiffré en '28' modulo 26, donc devient '2', lu "B"
"A" codé '1' sera chiffré en '2' module 26, donc reste '2', lu "B"
Comment déchiffrer un "B" ?

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

Christophe HENRY wrote:

2/ Si on reste dans un espace d'arrivé de 26 valeurs, il va y avoir
des collisions dès qu'on passe les résultats au modulo. En voici une :
"N" codé '14' sera chiffré en '28' modulo 26, donc devient '2', lu "B"
"A" codé '1' sera chiffré en '2' module 26, donc reste '2', lu "B"
Comment déchiffrer un "B" ?

C'est surtout qu'une clé ne serait plus unique, bref, une collision quoi...

--
AMcD®

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

Raymond,

Lorsque vous avez décidé de développer AllCipher, avez-vous d'abord créé
votre propre langage et développé le compilateur dont vous aviez besoin ?
Non. Pourquoi ? Parce que des outils éprouvés, fiables et reconnus par la
communauté sont disponibles (et probablement parce que vous n'avez pas les
compétences nécessaires).

Pourquoi ne pas faire la même chose avec l'algorithme de chiffrement ? Il
existe de nombreux algos reconnus, dont la fiabilité n'est plus à mettre en
doute, et dont l'utilisation dans votre produit donnerait à celui-ci une
crédibilité qu'il n'atteindra jamais avec un algorithme "maison", quel qu'il
soit. Certains algorithmes sont le fruit d'années d'études et ont été
décortiqués et testés par des dizaines de milliers spécialistes à travers le
monde. Je pense que vous serez assez honnête pour reconnaître que vous ne
pourrez pas, à vous seul, égaler le talent et le travail de toutes ces
personnes.

Si je peux me permettre un conseil en tant que concitoyen Canadien, jetez
votre bidouillage actuel et intégrez 3DES, Blowfish, AES (voire même RSA) à
AllCipher. Je suis persuadé que les critiques actuelles (et justifiées) à
votre égard sur ce forum cesseront (ou du moins changeront si, par exemple,
l'implémentation de l'algorithme est maladroite).

Michel
(Montréal, Canada)

"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de news:
%noyd.27214$GK5.1296164@news20.bellglobal.com...

(...suite)

Bonjour,

Je vais vous donner ici un petit problème qu'on retrouve seulement en
partie dans AllCrypter.

Si vous ne trouvez pas que cette façon de faire soit passablement sûr,
alors je vous demanderais de nous détailler au moins un petit exemple pour
le démontrer. Donc, je suis prêt à prendre vos conseils si vous pensez
que ce petit exemple simplifié ne vaut rien.



Voici l'exemple (ici je ne fais que des additions et ne fais pas de Xor
ni de Modulo comme il y a dans la version 3 dont je veux mettre les
calculs sur Internet après sa sortie):



Clef en clair: 12 ( en ascii = 49 50)

Texte à crypter: 345 (en ascii = 51 52 53)

J'aligne donc pour plus de clarté:

12 = clef

345 = texte à chiffrer

ou en ascii:

49-50

51-52-53



On crypte le caractère 3 (ascii 51) en faisant 49+51+522

On crypte le caractère 4 (ascii 52) en faisant 50+52+535

On crypte le caractère 5 (ascii 53) en faisant 49+53+491

Le texte crypté (en ascii pour mieux voir) donnerait 152 155 151





Et si on a:

155 = clef

251= texte à chiffrer

ou en ascii:

49-53-53

50-53-49



On crypte le 1er caractère (ascii 50) en faisant 49+50+532

On crypte le 2e caractère (ascii 53) en faisant 53+53+495

On crypte le 3e caractère (ascii 49) en faisant 53+49+491

Le texte crypté (en ascii pour mieux voir) serait identique au précédent
152 155 151





La question est: "Est-il possible de décrypter ces trois caractères
(ascii= 152-155-151) avec ce simple petit algorithme sans connaître la
clef ?"

Dans cette seule condition, je pense que 'non' et je pense que c'est
même impossible. Et pourtant un enfant de 10 ans pourrait crypter de
cette façon.

Car en faisant l'inverse, il faudrait deviner le premier caractère de
la clef et deviner le dernier caractère non crypté du chiffré. Alors
comment pourrait-on trouver l'avant dernier caractère si on n'a pas trouvé
le dernier caractère? Et comment trouver le premier caractère si on n'a
pas trouvé le 2e caractère? Il vous serait peut-être plus difficile de
déchiffrer le cryptogramme de cette façon que d'essayer toutes les clefs
possibles à l'endroit où on tape la clef dans le logiciel.





Certaines personnes n'additionnent que chaque caractère de la clef avec
le caractère actuel (non crypté) du texte à crypter. Cette façon de faire
ne donne rien puisqu'en cryptant des caractères NUL (c'est à dire, ascii
zéro) on lira très clairement la clef qui se répète dans le chiffré.

Les caractères zéro peuvent se trouver dans un fichier '.mov' ou '.jpg'
par exemple. Après avoir pris connaissance de la clef dans le chiffré il
suffirait alors d'écrire cette clef pour décrypter le tout. Car ceci
donnerait:

Clef en clair: 12 (en ascii = 49 50)

Texte à crypter: (en ascii= 0 0 0)



En cryptant le caractère Nul (ascii 0) on fait 49+0I

En cryptant le caractère Nul (ascii 0) on fait 50+0P

En cryptant le caractère Nul (ascii 0) on fait 49+0I

Le texte crypté donnerait la clef elle-même en clair = (en ascii) 49 50 49


J'attends vos suggestions.

r.h.

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

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

dans notre exemple, si la clef initiale génère une autre clef (qui
servirait pour le cryptage/décryptage) mais que la 1re clef initiale n'est
pas utilisée dans le cryptage seriez-vous du même avis pour dire que la
réutilisation d'une même clef faciliterait les déchiffrements?


Car si je ne me trompe c'est la façon qu'IBM a faite dans son algo de
cryptage qu'il a vendu au U.S. , et il utilise des permutations et des XOR
et tout repose sur la clef initiale. Si c'est bien ça, alors partagez-vous
le même avis que certaines personnes lorsqu'ils disent que tous les algos
peuvent être cassés mais qu'ils sont seulement plus ou moins compliqué à
casser et que ça peut seulement être une question de temps pour qu'on le
casse, quitte à prendre des années même?

Cordialement

r.h.

S'il est valable pour
les transferts sensibles et ponctuels (et là, on xorise), il est (me
semble) inadapté à un usage régulier.

Bonjour Michel,

Sat, 25 Dec 2004 04:04:27 GMT, "mif" <mif@mif.com> écrivait:

Si je peux me permettre un conseil en tant que concitoyen Canadien, jetez
votre bidouillage actuel et intégrez 3DES, Blowfish, AES (voire même RSA) à
AllCipher. Je suis persuadé que les critiques actuelles (et justifiées) à
votre égard sur ce forum cesseront (ou du moins changeront si, par exemple,
l'implémentation de l'algorithme est maladroite).

Je suis néophyte en cette matière, mais si je concevais un programme de
chiffrage dont l'efficacité ne ferait aucun doute, il y aurait un moyen
très simple de le vérifier :

Offrir une somme substantielle à la première personne capable de
retrouver le texte en clair à partir d'un texte chiffré que je mettrais
à la disposition de tous.

Roland
--
***************************************
Il faut mettre un frein à l'immobilisme
***************************************

"Roland" <demandez@la.moi> a écrit dans le message de news:
194qs0pfpcn7qoo2rlvi3om60eo5g4glo1@4ax.com...

Bonjour Michel,

Sat, 25 Dec 2004 04:04:27 GMT, "mif" <mif@mif.com> écrivait:

Si je peux me permettre un conseil en tant que concitoyen Canadien, jetez
votre bidouillage actuel et intégrez 3DES, Blowfish, AES (voire même RSA)
à
AllCipher. Je suis persuadé que les critiques actuelles (et justifiées) à
votre égard sur ce forum cesseront (ou du moins changeront si, par
exemple,
l'implémentation de l'algorithme est maladroite).

Je suis néophyte en cette matière, mais si je concevais un programme de
chiffrage dont l'efficacité ne ferait aucun doute, il y aurait un moyen
très simple de le vérifier :

Offrir une somme substantielle à la première personne capable de
retrouver le texte en clair à partir d'un texte chiffré que je mettrais
à la disposition de tous.

Bonjour,

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

a+

r.h.

"Roland" <demandez@la.moi> a écrit dans le message de news:
194qs0pfpcn7qoo2rlvi3om60eo5g4glo1@4ax.com...

Bonjour Michel,

Sat, 25 Dec 2004 04:04:27 GMT, "mif" <mif@mif.com> écrivait:

Si je peux me permettre un conseil en tant que concitoyen Canadien, jetez
votre bidouillage actuel et intégrez 3DES, Blowfish, AES (voire même RSA)
à
AllCipher. Je suis persuadé que les critiques actuelles (et justifiées) à
votre égard sur ce forum cesseront (ou du moins changeront si, par
exemple,
l'implémentation de l'algorithme est maladroite).

Je suis néophyte en cette matière, mais si je concevais un programme de
chiffrage dont l'efficacité ne ferait aucun doute, il y aurait un moyen
très simple de le vérifier :

Offrir une somme substantielle à la première personne capable de
retrouver le texte en clair à partir d'un texte chiffré que je mettrais
à la disposition de tous.

Même en offrant une somme très substantielle, la somme de travail obtenue
pour tester la solidité de votre algo n'atteindrait *JAMAIS*, et de très
loin, ce qui a été effectué sur les algos "standards". De plus, même si
votre travail est de même qualité (ce qui est peu probable), la confiance de
vos clients envers votre produit ne pourra pas être aussi forte que si un
AES par exemple a été utilisé.

Roland
--
***************************************
Il faut mettre un frein à l'immobilisme
***************************************

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

dans notre exemple, si la clef initiale génère une autre clef (qui
servirait pour le cryptage/décryptage) mais que la 1re clef initiale n'est
pas utilisée dans le cryptage seriez-vous du même avis pour dire que la
réutilisation d'une même clef faciliterait les déchiffrements?

Pareil.
C'est le principe utilisé - par exemple - pour les clé de chiffrement
Wifi. Plutôt que de faire entrer une suite de caractères hexadécimaux
d'entropie maximale, l'utilisateur peut entrer une phrase de son crû
qu'il pourra copier plus facilement mais dont le nombre de variantes
(l'entropie, en gros) sera moindre.

Soient 'Ci' la clé initiale et 'Cf' la clé finale. Puisqu'on passe de Ci
à CF, il existe une application de l'une vers l'autre qu'on notera 'f()'.

Ainsi : Cf = f(Ci)

Le chiffrement se fera avec Cf. Donc :
C = M + K (C=chiffré, M=mot(clair), K=cle)
(Si on revient à ma notation déjà utilisée.)

devient : C = M + Cf
De là : C = M + f(Ci)

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

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

Voici un cas tiré de mon expérience sur Drdos pour illustrer ce rejeu :
A l'époque on pouvait interdire l'accès à un fichier par l'ajout d'un
mot de passe. Rien n'était chiffré mais le système d'exploitation
interdisait l'accès au fichier sans le césame qui était stocké dans la
table d'allocation des fichiers.

Il me semble que le code était fait sur 2 octets (ou alors, pas beaucoup
plus). Pourtant on pouvait rentrer des mots de passe (alphabétiques) bien
plus grands. Il y avait des collisions : le Ci étant le mot de passe de
l'utilisateur et le Cf étant cette séquence de 2 octets, il s'avérait
qu'il existait plusieurs Ci pour le même Cf. f() était une fonction de hachage.

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

Nos deux mots de passe étaient équivalents.

Car si je ne me trompe c'est la façon qu'IBM a faite dans son algo de
cryptage qu'il a vendu au U.S. , et il utilise des permutations et des XOR
et tout repose sur la clef initiale.

C'est une façon très courante de procéder mais qui a les défauts de
ses avantages. Supposons qu'une application de cryptograhie autorise des
mots de passes alphabétiques de 4 lettres de "A" à "Z", pour simplifier.
Le raisonnement pourra être étendu à l'ASCII, UTF-78 ou EBCDIC-345...

Il y a 456'976 = 26^4 possibilités de composer ces mots de passe. En
terme d'entropie on arrive à 18,8 bits pour Ci.

Supposons que la clé en question fasse 32 octets, soit 4 octets, soit 4
caractères pouvant varier de 0x00 à 0xFF. Elle a une entropie de 32
bits, munie de 4'294'967'296 possibilités pour Cf.

L'espace des Cf étant généré par les Ci, sa cardinalité est
normalement identique si on suppose que f() est injective. Autrement dit,
alors que les Ci occupent tout leur espace (possibilités de 4 lettres
"A" à "Z") l'espace des Cf est un-sous espace des possibilités des
séquences de 256 bits. Il y a des clés Cf qui ne seront jamais
utilisables.
Sur les 4'294'967'296 de possibilités affichées pour une
clé de 256bits, il y a en fait que 456'976 d'utilisés. Dans le meilleur
des cas, l'application f() est injective (Deux Ci différents font deux Cf
différents par f), sinon il y aura des collisions et l'entropie finale
est encore diminuée.

A peu près 1/10'000 des clés seront en réalité utilisables : voilà le
type de problème que procurent ces fonctions de conversion, une illusion
de sécurité vulnérable aux attaques par dictionnaire.

D'une manière générale, la force de la clé "finale" est au mieux de
l'ordre de la force de la clé "initiale". Trouver une clé "finale" est
aussi dur que de trouver une clé "initiale". Si on veut faire des clés
finales fortes, il faut agrandir la taille des clé initiales. C'est la
raison de l'existence du terme "phrase de passe" sur GnuPg.

Pour notre exemple, si on conserve les lettres de "A" à "Z" et si on
suppose naïvement que l'utilisateur les utilisera au hasard, il faudra
monter à 7 caractères pour disposer de la même complexité. 7
caractères alphabétiques pour un "mot de passe" de 4 caractères pleins.
La longueur de la clé initiale doit en fait être plus grande
puisque personne n'utilisera de clé du type "AEZMPRI" mais utilisera des
mots intelligibles.

Si c'est bien ça, alors partagez-vous
le même avis que certaines personnes lorsqu'ils disent que tous les algos
peuvent être cassés mais qu'ils sont seulement plus ou moins compliqué à
casser et que ça peut seulement être une question de temps pour qu'on le
casse, quitte à prendre des années même?

Il n'y a pas de rapport direct entre les deux parties du post, mais je
suis du même avis.
Tous les algos peuvent être cassés, sauf ceux équivalent à l'OTP
souvent désigné par son opérateur, le xor. Sous certaines conditions
d'usage (hasard, utilisation de la clé, canal sécurisé, ...) l'OTP est
incassable.

Son inconvénient est qu'il impose beaucoup de contraintes. Alors on
utilise des chiffrements dont la durée de cassage (force brute) jouxte
l'age de l'univers, du moins jusqu'à ce qu'on trouve de meilleures
techniques de cryptanalyse.
A mon humble avis, c'est parce que le domaine de variation des clés
possibles est très petit par rapport aux données ; problème que l'OTP
n'a pas puisque, justement, les dimensions des ensemble d'arrivée, de
départ et de clé sont de taille similaires.

Le chiffrement (sauf le xor) a pour but concrêt de protéger contre le
temps. Selon les applications, on peut confondre une durée très longue
et l'infini. Pour d'autres, non.

Au plaisir,

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

Raymond H. wrote:

Bonjour,

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

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

Si tu dissimules ton algo, il va en découler une batteries d'inconvénients,
entre autre :

- Peu de gens vont se soucier de ton cas. Avec l'algo, tu peux commencer à
analyser et étudier directement. Sans algo, il faut travailler en aveugle,
ou désassembler, etc. Long, pénible si t'es pas un spécialiste. Les
cryptographes pro ont autre chose à faire ;

- Aucun algo sûr n'est secret. Élaborés par des matheux, testés par des
spécialistes, etc. Pourquoi choisir un truc dont on ne sait pas comment ça
marche alors que tu en as de publics et de certifiés sûrs ? Un peu de sens
commun mon ami...

- Aucun professionnel ne dissimule son algo. Donc, tu vas, au minimum,
passer pour un amateur :-). Comme dit plus loin, si tu ne crains rien, si tu
penses que ta méthode est performante eh bien publie-la ! Aucune technique
secrète n'a jamais été performante bien longtemps ;

- Quand la méthode est publique, tu obtiens un débat public. Si tu
dissimules, tu risques de n'avoir aucun débat. Comment savoir alors si
quelqu'un dans son coin na pas déjà craqué ta méthode et l'utilise déjà à
tes dépends ?

- Des gens qui déboulent sur les forums avec un
algo-secret-miracle-que-j'ai-moi-même-pondu-en-regardant-Friends-à-la-TV, ça
fait 20 ans qu'on en voit. Cela fait également 20 ans qu'aucun n'est parvenu
à ne pas se faire casser :-) ;

- Enfin, dans ton cas, tu ne vas finir que par aiguiser la curiosités de
gugusses dans mon genre, habitués à hacker, cracker, RE, etc. Univers de
machos à la grande gueule (du moins apparente), accoutumés à voir débouler
sans cesse des pseudos-génies du code tous plus malins les uns que les
autres. Univers où quand tu casses, tu casses ! Avec donc force quolibets,
railleries et moqueries en tous genre. Tu passes donc pour un bel idiot.
Franchement, je préfèrerai, moi, me faire casser par un cryptographe, gens
bien plus reservés, posés et courtois que des hackers :-).

Pour terminer, quelques remarques générales :

- Il te faut choisir un autre langage de programmation que le Visual Basic.
J'ai évoqué dans un autre post les raisons (complétées par je ne sais plus
qui). Cela ne fait vraiment pas très sérieux d'utiliser un tel langage.
D'une manière générale, je ne saurai que trop te conseiller d'isoler le
chiffrement/déchiffrement dans une DLL et de coder le frontal d'utilisation
ailleurs. C'est ainsi que l'on pratique en crypto standard ;

- Tu vends ton logiciel. Tu viens ici demander qu'on l'éprouve.
Gratuitement. Cela fait un peu prendre les gens pour des imbéciles. Si tu es
si sûr de ta méthode, offre un prix. Avantage, des tonnes de gens vont s'y
interesser et si personne n'y arrive, t'auras la pub toute faite... Et puis
bon, faut que je change de PC :-).

Voilà. Comprend bien, enfin, que ce n'est pas parce que personne ne te le
casse effectivement que ton algorithme est sûr pour autant. Beaucoup
d'intevenants ici sont de gros cadors en cryptographie, s'ils te disent,
après une analyse sommaire, que c'est nul, tu peux les croire aveuglément,
c'est nul ! Simplement, pour pleins de raisons dont certaines évoquées plus
haut, ils n'ont pas plus de temps à perdre que celui passé à tirer les
premiers commentaires qu'ils fournissent en général à toute méthode
présentée.

--
AMcD®

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