[C / WIN32] RATLIB - CRYPTER FACILEMENT EN RC4, AES ET TEA
Bel0
Messages postés
71
Date d'inscription
mercredi 14 avril 2004
Statut
Membre
Dernière intervention
14 septembre 2007
-
14 sept. 2007 à 16:50
selmaSara Messages postés 1 Date d'inscription lundi 13 février 2012 Statut Membre Dernière intervention 3 avril 2012 - 3 avril 2012 à 15:54
selmaSara Messages postés 1 Date d'inscription lundi 13 février 2012 Statut Membre Dernière intervention 3 avril 2012 - 3 avril 2012 à 15:54
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/44080-c-win32-ratlib-crypter-facilement-en-rc4-aes-et-tea
https://codes-sources.commentcamarche.net/source/44080-c-win32-ratlib-crypter-facilement-en-rc4-aes-et-tea
3 avril 2012 à 15:54
19 oct. 2008 à 01:52
J'ai fait une nouvelle version avec plus d'algos mais il me reste quelques bugs a corriger avant de poster..
Neo_Fr
18 oct. 2008 à 07:34
J'essaye d'ajouter des cryptage à cette bibliothèque, j'ai heurter n obstacle , je me demande si c'est possible enfin ? Il comment dois - je proceder si je veux garder l'interface graphique de Cryptfile ?
6 janv. 2008 à 00:38
merci pour les codes,
mais j'ai une question, pourquoi quand on fait la compilation d'un seule code (exemple le aes.c) il y aura beaucoup des erreurs, notant que j'ai utilse le compilateur c et linux, mais la meme resultat.
14 sept. 2007 à 19:49
1) merci pr le lien sur les standards du padding mais serieusement mise a part un pb de standard je ne pensse pas que cela cause un pb de sécurité
2) Tu a raison cette methode n'est pas tres sure, je suis en train de faire un fonction qui crypte en memoire puis l'ecrit ds un fichier, je ferais bientot une maj
3)Effictevement il ya des donnés en trop ds le fichier qui sont enlever ici:
if(!RetValue) UnFixFile(OutFile);//Si la fct de decryptage reussi,on restaure
6) C'est vrai que c'est pas tres sure mais a la base j'ai plutot fait cette fonction pour pouvoir verifier l'integrité du fichier apres le decryptage
Merci pr tes conseilles j'essayerais de m'en rapeller quand je ferait une maj..
Neo_Fr
14 sept. 2007 à 16:50
Etant donnée que tu utilises des fonctions de chiffrement fonctionnant par bloc, tu dois faire en sorte que la taille du bloc du cipher et la taille du fichier correspondent, ce que tu as bien fait. En anglais, on dit qu'on rajoute du "padding". Dans ton cas, tu rajoutes uniquement des zéros à la fin du fichier. Ce n'est pas vraiment la meilleur façon de procéder. Il y a des "standards" de padding (cfr: http://en.wikipedia.org/wiki/Padding_%28cryptography%29).
2° Dans FixFile, tu rajoutes le padding "in place" dans le fichier et ensuite tu le retires ... un peu barbare non ? :) Pourquoi ne pas le faire dans le buffer mémoire au lieu d'aller modifier le fichier, encrypter, enlever les mods dans le fichier.
3° DecryptFile (toutes)
Etant donné que tu ajoutes du padding au moment de l'encryption, tu vas avoir des données superflues au moment de la décryption. Tu DOIS les enlever pour reconstituer le fichier original.
4° Tu utilises les blocks ciphers en mode ECB, tu ferais mieux d'utiliser le mode CBC qui "dissimule" mieux les données. Une bonne illustration du pourquoi et une explication sur les autres modes est donnée à l'adresse suivante: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
5° Mot de passe -> Clé
Pour générer la clé à partir du mot de passe, il y a aussi des standards à utiliser de préférence ! (notamment PKCS5 défini dans le RFC2898 (http://tools.ietf.org/html/rfc2898)).
6° Signature de fichier (Le plus gros problème)
Le but d'une signature est de prouver l'authenticité du message. Je banalise un peu la chose ...
Premièrement, on effectue un hash des données (ce que tu fais) et ensuite on signe le hash.
Le problème avec ce que tu as fait est le suivant. Si un attaquant modifie le fichier que tu as "signé", il doit aussi modifié le hash qui se trouve au début du fichier ... ce qui ne lui pose *AUCUN* problème étant donné que la fonction de hash est connue. Il est donc impossible de voir si qqn a modifié le fichier.
Par contre en signant le hash (avec ta clé privée en utilisant RSA en mode signature, clé privée que tu es le seul a possédé), n'importe qui peut vérifier si le hash a été modifié (en utilisant ta clé publique que tout le monde peut avoir).
Si ce que j'ai dit n'était pas clair (et c'est sans doute le cas :|), je te conseille de consulter (http://en.wikipedia.org/wiki/Digital_signature).
---
Je crois que j'ai fait le tour des plus gros défauts (cryptographiques) du programme. Le code en soit est correct et la séparation des différentes fonctions est plutôt bonne. Rien à redire de ce coté.
Créer des programmes qui utilisent correctement la cryptographie n'est pas quelque chose d'évident à faire. Si un jour, tu dois en utiliser dans tes programmes de façon "plus professionnel", je te conseille d'utiliser la librairie OpenSSL.