CRYPTAGE PUISSANT 128 BITS QUASI-INCASSABLE(ALGORITHME BAPTISÉ XES)

Commentaire de lumesh le 18/12/2003 18:48:44

Domage que je n'ai plus VB6 je me serais tenté une traduction ://
si c ke des fonctions dans un module, et si tu as un peu de temps
mets le en RTF et propose le ds le ZIP ...
JE c pas si jen serait capable mais ca vaut le cp de tenter ....

Commentaire de JcDuss le 18/12/2003 19:21:28

KaViDee a dit : "vous avez un avantage: l'algorithme ;)"

c'est justement là qu'on peut voir si un algo est puissant

par ex: le rsa, le principe est facile, mais ca suffit pas a decrypter sans clé

Commentaire de Xya le 18/12/2003 19:43:22

>seul point faible: il ajoute des espaces au texte décrypté si la taille du texte non crypté n'est pas un multiple de 16

La technique standard de padding (ajouter des données pour arriver à des blocs de taille fixe) est d'ajouter x octets de valeur x à la fin des données, s'il manque x octets pour faire un nombre rond de blocs.  S'il y a un nombre rond de blocs, on ajoute un bloc complet avec comme valeur la taille du bloc  (ici 16 octets avec la valeur 16).

Après le decryptage, il suffit de lire le dernier octet décrypté et de retirer x octets aux données, où x est la valeur du dernier octet:


Données claires (entrée):
F6 A5 0C 78 69 ED
On ajoute le padding, il manque 10 octets (0A en hexa):
F6 A5 0C 78 69 ED 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A
On crypte (ici des valeurs aléatoires, c'est juste pour montrer le fonctionement)
D6 45 39 F6 00 A9 BD F9 9F 04 78 AD 39 2F 8B 12
On décrypte (on ne connait pas la longueur des données initialies)
F6 A5 0C 78 69 ED 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A
On retire 0A octets à la fin du bloc:
F6 A5 0C 78 69 ED

Sinon balèze l'algo comme premier essai !

Et pour adapter ton algo en C# j'essaierai bien,  le code n'a pas l'air trop long. Ca pourrait être sympa aussi de le faire en style .net, genre dériver SymmetricAlgorithm, CryptoStream & co, pour après crypter des fichiers ou des transmissions de sockets à la volée :)

Xya

Commentaire de BruNews le 18/12/2003 20:05:19 administrateur CS

Pourquoi plutot C# que C ou ASM, si est tres bon ton algo vaut mieux en faire une dll en code compile le + rapide possible.
Ne te semble pas ?

Commentaire de KaViDee le 18/12/2003 20:21:31

Brunews-> D'accord avec toi, mais c'est d'un point de vue personnel, j'apprend le C# en ce moment et ça m'intéresse plus.
D'un autre coté en ce qui concerne la rapidité t'as pas tort c'est pour ça que j'aimerais les 2 traductions ;)

Xya->Dans mon cas c'est rotation (désolé si j'ai pas employé les bons termes). Et pour le padding c'est bon j'ai tout bien compris :) je fais ça le + vite possible ;)

Commentaire de KaViDee le 18/12/2003 20:52:52

Voila j'ai fais le Padding mais il reste un problème:
si la longueur de la chaine a crypter est un multiple de 16 et que le dernier caractère est compris entre 1 et 16 en hexa ça va enlever entre 1 et 16 caractères au décryptage :/

As-tu une solution ?

Commentaire de KaViDee le 18/12/2003 21:08:20

Non, toujours un problème mais cette fois c'est si la chaine à crypter est un multiple de 16 et si le dernier caractère est "1".
Pour "1111111111111111" il me sort "111111111111111" soit un caractère de moins qu'au départ.
Et là, je ne vois plus de solution... :-/

Commentaire de KaViDee le 18/12/2003 21:46:57

Wow c'était compliqué mais j'y suis arrivé !!
La source est a jour :) Enjoy...

Commentaire de KaViDee le 18/12/2003 22:13:16

Po grave, pendant ce temps j'ai réglé l'algo est c'est bon il est stable ;)
Je sais pas si t'a retéléchargé le zip en tout cas si c'est pas le cas fais le ya plusieurs "nouveautés" dans le code a cause du padding.
Merci à toi et tiens moi au courant :)

Commentaire de gabchampagne le 19/12/2003 00:37:32

J'ai effectué des modification (Minimes) à ton code :
1- Création de l'évènement Finish
2- Création de l'évènement progress pour éviter d'avoir à aller modifier la classe :
Utilisation --> public withevents ToCrypt as  XES

pi dans form_initialize :
set ToCrypt=new XES

pi dans unload :
set ToCrypt=nothing

Et j'ai enlever tous les Dim ToCrypt as XES

Commentaire de Mindiell le 19/12/2003 10:58:33

Desole gabchampagne, mais en france c'est interdit de faire du cryptage > 128... :)

Je vais tenter moi aussi de le decrypter...

Commentaire de kha le 19/12/2003 12:27:55

Salut !
Tout d'abord bravo pour ce code !

Mais qq petites remarques : je pense qu'avant de dire qu'il est quasi incassable il faudrait le tester dans des cas réels et essayer de le casser pr voir si c'est possible.
Je trouve que c'est trop périodique : par exemple si tu utilise la clé "a" et le texte "abcdefghijklmno" (15 char. pour en obtenir 16 cryptés) et que apres tu mets le texte "abcdefghijklmnoabcdefghijklmno" (30 char pr en obtenir 32 cryptés) il y a des blocs (du a ton code comme tu fais des matrices de 4x4). apres, en rajoutant un "p" a la fin, tu vois que ca ne change pas bcp...
a mon avis il est facilement crackable, au moins par une algo bruteforce mais bon... je v essayer on verra.

sinon ya un bug :
si tu utilise la clé "a" pour crypter la chaine "bbbbbbbbbbbbbbb" et que tu decrypte ce que tu obbtient avec la meme cle, tu n obtient pas 15 "b" mais "bbbb". j ai pas encore vu ton code en detail donc j ai pas vu ou est le pb.

Commentaire de KaViDee le 19/12/2003 12:52:13

Oui je viens juste de refaire une MAJ a cause du bug que je viens de corriger :)
Désolé pour le changement.
Voila normallement ya pu de bugs :)

Commentaire de KaViDee le 19/12/2003 16:52:59

Pour ce qui est de l'algo, oui j'ai fais ça tout seul après avoir lu un peu de doc sur la crypto.
Mais qu'entends tu par "coder une chaine de 256 bits à 0" ? à quoi correspond 0 ?
Aurais tu une solution plus ou moins concrète pour consolider l'algo ?? et à quoi ça pourrais servir de mettre la taille du texte ?? juste pour emmeler celui qui essayerais de décrypter ??

Si tu as d'autres conseils qui pourraient le faire évoluer je suis toujours preneur ;)
En tk, merci à toi :)

Commentaire de gabchampagne le 19/12/2003 17:51:31

Je vais te l'envoyer. Mais, je ne suis pas sûre que ça va être capable de crypter des fichiers de n'importe quelle taille dans l'état actuel car la mémoire risque d'être surexploitée. Le principe pour Lire/Écrire avec ma classe TextStream est simple.

Commentaire de Warny le 01/01/2004 21:40:02

=>Golfy
En fait ça dépend
On peut considerer une fonction de cryptage de la façon suivante :
soit une f une fonction réversible,k une clef,  m une valeur représentant une donnée et x le message codé
On peut écrire
x = f(k, m)
comme f est reversible on a aussi
m = f-1(k, m) (f-1 est la fonction inverse de f)

il existe des cas où f-1 = f (cas de la fonction xor par exemple)
ou plus souvent des cas où f-1(k) = f(-k) (addition)
Si on utlise de telle fonction un codage supplémentaire n'entrainera pas une plus grande complexité du message codé. Je m'explique

dans le premier cas f2(k) = f(f(k)) comme f-1 = f on peut ecrire
f2(k) = f-1(f(k)) = k on revient donc au message
dans le deuxième, on tombe sur une multiplication simlpe de la clef
Dans les deux cas on ne gagne pas en complexité

Dans le cas présenté ici, l'avantage de la substitution (serpentisation) c'est que l'inverse de la fonction n'est pas la fonction elle même et que appliquer plusieurs fois la fonction ne revient pas à modifier la clef pour n'appliquer qu'une fois la fonction.

La réponse à ta question doit avoir une approche mathématique (Renseigne-toi sur la théorie des corps finis). Tout dépend en fait de la (ou des) fonction(s) utilisée(s).

Pour la petite précision ta question est mal posée : si ton message codé une deuxième fois était strictement indéchiffrable ça ne serait pas interressant (vu que plus personne ne pourrait le lire)

Commentaire de Leirn le 20/01/2004 13:32:23

concernant la convertion en c par rapport a c#, je tiens a rappeler ke le c# n est pas tres portable si tu veux aue des non windosiens s interressent a ton code...