lumesh
Messages postés564Date d'inscriptionjeudi 21 février 2002StatutMembreDernière intervention 7 novembre 2008
-
18 déc. 2003 à 18:48
cs_azerty25
Messages postés1114Date d'inscriptionjeudi 19 décembre 2002StatutMembreDerniè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.
cs_azerty25
Messages postés1114Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention 6 mai 2007 30 août 2004 à 16:36
Peut etre un peu tard mais j'ai essayé, il est d'ailleur très bien ton code, mais quand on met dans la clé le caractere "^", il sort un mot de passe éronné quand on décrypte mais affiche tout de même un morceau de la chaine a crypter
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 20 janv. 2004 à 13:41
Leirn ->
Pour la portabilité, tu vas sur http://www.go-mono.net/ ils s'en chargent (c'est Novell derrière).
Leirn
Messages postés30Date d'inscriptionlundi 13 mai 2002StatutMembreDernière intervention12 février 2004 20 janv. 2004 à 13:32
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...
cs_Golfy
Messages postés2Date d'inscriptiondimanche 12 janvier 2003StatutMembreDernière intervention 4 janvier 2004 4 janv. 2004 à 09:03
Merci Warny pour ta brillante explication.
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 1 janv. 2004 à 21:40
=>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)
cs_Golfy
Messages postés2Date d'inscriptiondimanche 12 janvier 2003StatutMembreDernière intervention 4 janvier 2004 31 déc. 2003 à 11:37
Une question aux spécialistes de la cryptologie:
Si on recode une nouvelle fois le message codé, n'est il pas maintenant indéchiffrable ?
gabchampagne
Messages postés216Date d'inscriptionmercredi 2 avril 2003StatutMembreDernière intervention 5 mai 2004 19 déc. 2003 à 17:51
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.
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 19 déc. 2003 à 17:29
En fait, le truc c'est de coder une chaine de caractère où tout les caractères à coder ont la valeur null (0x00 en hexa) et correspondent à la taille de ta clef * 2
Si ça crypte sans faire de cycle, c'est que ton codage est bon, sinon, il faut reprendre un peu.
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 19 déc. 2003 à 16:52
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 :)
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 19 déc. 2003 à 16:04
Si tu as sorti ça tout seul chapeau !!!
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...
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 19 déc. 2003 à 12:52
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 :)
Mindiell
Messages postés558Date d'inscriptionjeudi 25 juillet 2002StatutMembreDernière intervention 5 septembre 20071 19 déc. 2003 à 12:46
kha,
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 ???
cs_kha
Messages postés38Date d'inscriptionvendredi 25 janvier 2002StatutMembreDernière intervention29 juillet 2004 19 déc. 2003 à 12:27
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.
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 19 déc. 2003 à 12:21
gabchampagne-> merci pour les modifs, pourrais tu me les envoyer à webmaster@kavidee-concept.fr.st ?
je vais voir ce que tu as fais ;)
Mindiell
Messages postés558Date d'inscriptionjeudi 25 juillet 2002StatutMembreDernière intervention 5 septembre 20071 19 déc. 2003 à 10:58
Desole gabchampagne, mais en france c'est interdit de faire du cryptage > 128... :)
Je vais tenter moi aussi de le decrypter...
gabchampagne
Messages postés216Date d'inscriptionmercredi 2 avril 2003StatutMembreDernière intervention 5 mai 2004 19 déc. 2003 à 01:15
j'ai aussi inclu quelque chose pour crypter/décrypter un fichier seulement avec des apis
gabchampagne
Messages postés216Date d'inscriptionmercredi 2 avril 2003StatutMembreDernière intervention 5 mai 2004 19 déc. 2003 à 00:37
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
gabchampagne
Messages postés216Date d'inscriptionmercredi 2 avril 2003StatutMembreDernière intervention 5 mai 2004 19 déc. 2003 à 00:22
c'est très bien. Ce que j'aimerais vraiment voir, c'est un algorithme de cryptage > 128. Là, ca serait puissant. C'est hot. Je te conseil de montrer sur des sites spécialisés.
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 22:13
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 :)
Xya
Messages postés103Date d'inscriptionlundi 8 juillet 2002StatutMembreDernière intervention24 novembre 2005 18 déc. 2003 à 22:05
Désolé KaviDee, j'ai pas pu repondre à temps parce que j'etais en train de manger et ça s'est éternisé :)
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
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 21:46
Wow c'était compliqué mais j'y suis arrivé !!
La source est a jour :) Enjoy...
cs_JcDuss
Messages postés37Date d'inscriptionjeudi 9 janvier 2003StatutMembreDernière intervention23 avril 2004 18 déc. 2003 à 21:14
xya a dit : "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)."
donc si ca tombe tout pile a 16 t'en remets 16 de plus
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 21:08
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... :-/
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 20:59
C'est bon j'ai trouvé :D
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 20: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 ?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 18 déc. 2003 à 20:32
Alors voyez tous ensemble, si est si bon que cela on en fera une dll en ASM version turbo.
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 20:21
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 ;)
Xya
Messages postés103Date d'inscriptionlundi 8 juillet 2002StatutMembreDernière intervention24 novembre 2005 18 déc. 2003 à 20:09
Aucun risque de 'manger' des caractères, on enlève exactement le même nombre de caractères que l'on ajoute. Et comme on ajoute le padding à la fin, aucun risque de confondre le padding avec les données. Le seul risque c'est de décrypter avec une mauvaise clef, les derniers caractères ne sont plus le padding original, c'est pour ça qu'il faut tester pour enlever le padding que la dernière valeur < ou = taille du bloc.
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
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 18 déc. 2003 à 20:05
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 ?
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 19:50
ça a l'air pas mal cette technique mais il n'y a pas de risques de "manger" des octets sur un texte qui utiliserais les meme caractères que le padding ?!
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 :)
Xya
Messages postés103Date d'inscriptionlundi 8 juillet 2002StatutMembreDernière intervention24 novembre 2005 18 déc. 2003 à 19:43
>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
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 19:30
c'est justement pour ça que je veux voir si il est fiable ;) héhé
cs_JcDuss
Messages postés37Date d'inscriptionjeudi 9 janvier 2003StatutMembreDernière intervention23 avril 2004 18 déc. 2003 à 19:21
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é
KaViDee
Messages postés262Date d'inscriptiondimanche 1 septembre 2002StatutMembreDernière intervention18 juin 2008 18 déc. 2003 à 19:01
Done! Enjoy :D
mais t'aurais pu quand meme ouvrir le .cls dans un notepad lol
lumesh
Messages postés564Date d'inscriptionjeudi 21 février 2002StatutMembreDernière intervention 7 novembre 2008 18 déc. 2003 à 18:48
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 ....
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 ....