CRYPTAGE PUISSANT 128 BITS QUASI-INCASSABLE(ALGORITHME BAPTISÉ XES)
lumesh
Messages postés
564
Date d'inscription
jeudi 21 février 2002
Statut
Membre
Dernière intervention
7 novembre 2008
-
18 déc. 2003 à 18:48
cs_azerty25 Messages postés 1114 Date d'inscription jeudi 19 décembre 2002 Statut Membre Dernière intervention 6 mai 2007 - 30 août 2004 à 16:36
cs_azerty25 Messages postés 1114 Date d'inscription jeudi 19 décembre 2002 Statut Membre Dernière intervention 6 mai 2007 - 30 août 2004 à 16:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/18818-cryptage-puissant-128-bits-quasi-incassable-algorithme-baptise-xes
https://codes-sources.commentcamarche.net/source/18818-cryptage-puissant-128-bits-quasi-incassable-algorithme-baptise-xes
30 août 2004 à 16:36
20 janv. 2004 à 13:41
Pour la portabilité, tu vas sur http://www.go-mono.net/ ils s'en chargent (c'est Novell derrière).
20 janv. 2004 à 13:32
4 janv. 2004 à 09:03
1 janv. 2004 à 21:40
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)
31 déc. 2003 à 11:37
Si on recode une nouvelle fois le message codé, n'est il pas maintenant indéchiffrable ?
19 déc. 2003 à 17:51
19 déc. 2003 à 17:29
Si ça crypte sans faire de cycle, c'est que ton codage est bon, sinon, il faut reprendre un peu.
19 déc. 2003 à 16:52
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 :)
19 déc. 2003 à 16:04
sinon, cet algorithme existe déjà : il s'agit de la deuxième étape du rijndael ou AES (sur 3) qui est le futur remplaçant du des-3
comme le fait remarqué kha, ton algorithme est périodique (code une chaine de 256 bit à 0 et tu verras la faiblesse)
voici l'explication, note que c'est assez complexe, l'explication inclus aussi les attaques possibles : http://home.ecn.ab.ca/~jsavard/crypto/co040401.htm
Sinon, pour interdire le cassage sur le dernier bloc, tu devrais positionner des octets qui t'indiquent la taille du fichier crypté (pas regroupés au début, sinon on cherchera à casser le début en fonction de la taille du fichier) et mettre n'importe quoi à la fin. Eventuellement, dans les conditions que je t'ai données, tu peux rajouter un petit nombre aléatoires de blocs à la fin qui ne servent à rien.
Bonne crypto...
19 déc. 2003 à 12:52
Désolé pour le changement.
Voila normallement ya pu de bugs :)
19 déc. 2003 à 12:46
tout est craquable, il suffit de trouver la bonne clef :)
KaViDee,
Pour le test a decrypter, tu l'as remis a neuf avec ton nouveau padding ou pas ???
19 déc. 2003 à 12:27
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.
19 déc. 2003 à 12:21
je vais voir ce que tu as fais ;)
19 déc. 2003 à 10:58
Je vais tenter moi aussi de le decrypter...
19 déc. 2003 à 01:15
19 déc. 2003 à 00:37
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
19 déc. 2003 à 00:22
18 déc. 2003 à 22:13
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 :)
18 déc. 2003 à 22:05
Sinon j'ai commencé à adapter ton algo en C#, pour l'instante je vise 'faire exactement la même chose qu'en VB' puis je verrai après pour le mettre au goût du C#, c'est à dire par exemple pour les rotation utiliser d'abord BinToVal et ValToBin.
Un truc à faire dès que ton algo est stable c'est de faire une fonction pour avoir des 'vecteurs tests' pour pouvoir s'assurer que la version VB et la version C# (ou les autres versions) donnent bien des résultats identiques.
Faire des vecteurs tests ce serait crypter plusieurs textes avec une même clée précise:
Clé "xyz"
Pour "KaViDee" on a "afdjç_hG"
Pour "XES" on a "ksjd"
...
Xya
18 déc. 2003 à 21:46
La source est a jour :) Enjoy...
18 déc. 2003 à 21:14
donc si ca tombe tout pile a 16 t'en remets 16 de plus
18 déc. 2003 à 21:08
Pour "1111111111111111" il me sort "111111111111111" soit un caractère de moins qu'au départ.
Et là, je ne vois plus de solution... :-/
18 déc. 2003 à 20:59
18 déc. 2003 à 20:52
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 ?
18 déc. 2003 à 20:32
18 déc. 2003 à 20:21
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 ;)
18 déc. 2003 à 20:09
Si on crypte un texte qui a pour dernier caractère le caractère du padding, on obtient toujours le texte original puisque on enlève un certain nombre de caractères identiques et non pas tous les caractères identiques à celui de la fin, qui le précèdent:
Données claires (entrée):
F6 A5 0C 78 69 0A
On ajoute le padding, il manque 10 octets (0A en hexa):
F6 A5 0C 78 69 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A
On crypte
45 39 F6 00 04 78 AD A9 BD F9 9F 39 2F 8B 12 D6
On décrypte (on ne connait pas la longueur des données initialies)
Ici il y a 11 caractères 0A mais on en retire que 10, comme 0A = 10 en décimal:
F6 A5 0C 78 69 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A
On retire 0A octets à la fin du bloc:
F6 A5 0C 78 69 0A
Il reste toujours notre caractère 0A final.
Sinon pour tes fonctions BinShiftL et BinShiftR, c'est bien des rotations de bits en gardant les bits 'qui sortent' ou c'est juste un décalage normal?
Décalage de 2 bits vers la gauche
10111010 devient 11101000
Rotation de 2 bits vers la gauche
10111010 devient 11101010
Ca pourrait être simplifié en C#, comme C# a son propre opérateur de décalage, on pourrait éviter de convertir la valeur d'un octet en binaire pour faire la rotation ou le décallage.
Xya
18 déc. 2003 à 20:05
Ne te semble pas ?
18 déc. 2003 à 19:50
J'espere que tu vois ce que je veux dire
Sinon j'essairai de faire ça mais pas ce soir, trop la flemme :p
en tk merci pour la remarque et si t'arrive a la traduire en C# envoie moi la webmaster@kavidee-concept.fr.st :)
18 déc. 2003 à 19:43
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
18 déc. 2003 à 19:30
18 déc. 2003 à 19:21
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é
18 déc. 2003 à 19:01
mais t'aurais pu quand meme ouvrir le .cls dans un notepad lol
18 déc. 2003 à 18:48
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 ....