Télécharger le zip
J'ai juste jetté un rapide coup d'oeil, et je sens que je vais apprendra pas mal de choses... mais c'est dommage que tout le systeme de cryptage ne soit pas dans le .h ca permettrait de l'exporter pour crypter des fichiers de scores pour des jeux par exemple... tandis que là, il y a du boulo à regfaire...
Tu crypte selon quel algorithme ?
Je viens de lire ton code. Pour commencer, bravo pour la clarté. C'est plutôt bien écrit (sauf un petit do while que j'ai décelé, en général on évite, mais bon...)D'après ce que j'ai lu, tu utilises un algorithme de César modifié, à savoir que le code de César, c'est juste une incrémentation de chaque lettre du fichier par une même valeur. Toi, tu utilise César en changeant de valeur à chaque lettre de façon cyclique avec ta clef. Je ne sais pas si tu t'y connais en cryptage, mais il faut savoir que cet algo est très facilement cassable. De plus, tu écrit directement la clef dans ton fichier, ce qui aide vraiment beaucoup le hacker potentiel. Pour finir, mais c'est moins grave, c'esdt assez dangereux de mettre une signature de fichier crypté : imagine qu'un fichier non crypté commence aussi par cette chaine, ton programme va foirer !
Quelle utilité de mettre la clé dans le fichier? Si tu connais pas la clef, le décryptage donne n'importe quoi, c'est tt aussi bien ^^ au pire, tu tapes un hashage du fichier original dans le fichier, en clair, et tu vérifies que le résultat après décryptage correspond au hashage initial, et tu n'affiches le résultat que si c'est le cas.Je trouve ça assez dangereux :/Et si ce que dit xurei est juste (et j'en doute pas ^^), ton cryptage, ben oui, il est cyclique, donc y aura moyen de s'en sortir pas trop difficilement si on sait quelque chose sur le contenu. Exemple: si c'est du texte en français, on fait une analyse statistique sur la fréquence des caractère selon leur position (modulo la longueur supposée de la clef, ça, forcément ...). Si c'est une image, on peut voir le début du fichier, souvent, il y a un tag propre au format, ou encore il y a le nom du programme qui l'a générée (comme pour les jpeg): ça aide bcp! etc etc.Pour améliorer ton cryptage, il faudrait que tu élimines les cycles, que ce soit plus désordonné (et pas un cycle désordonné, ça sert à rien :p))
Merci les gars pour vos commentaires.je veux juste vous dire que je met pas la clé de cryptage dans le fichier, mais plutot la somme des codes ascii de tout les caractéres qui composent la clé.
Ce qui revient au même : c'est très dangereux.Le type qui recherche la clef peut déjà déterminer à quelques caractères près le nombre de caractères...
Oui, euh, ça revient qd même pas au même, c'est déjà bcp moins dangereux ^^. Ceci dit, comme dit xurei, on peut facilement trouver une fourchette de longueur pr la clé, et ds le cas d'un cryptage cyclique, c'est la moitié du boulot! Seule façon de s'en sortir: utiliser des clés atypiques (pas que des caractères a à z, mais aussi des caractères non affichables, ¾ ■ þ etc etc etc.
sinon.ya t il un bon algo de cryptage ?
RSA :D
et pour savoir si l'utilisateur a entré la bonne clé ou non ?pour moi j met la somme des codes ascii de la clé ds le fichier ...y a t il autre methode ?
Ben y a pas besoin de vérifier. Si c'est pas la bonne clef, le contenu décrypté sera illisible, c'est tout.Faut a tout prix éviter de mettre des infos sur la clef dans le document.
wé.mais ca serai bien de savoir si le ga a entrer la bonne clé ou non ...
"oui, mais ce serait bien de savoir si le gars a entré la bonne clé ou non ..."c'est mieux non?enfin, passons.non, ce ne serait pas mieux: si il a la bonne clé, il récupère les infos: c'est transparent. s'il ne l'a pas: c'est pas lui qui doit les récupérer: il peut tjs crever.
Hum, à la limite, ce que tu peux faire c'est hacher le fichier crypté (cherche hash sur google si tu ne connais pas, mais sache que ta somme des valeurs ascii est un hachage). Quand tu cryptes, tu fais un hash que tu met en premier. Quand tu décryptes, tu hash le fichier décrypté. Si c'est la même chose, banco ! Encore une fois, c'est risqué... mais moins : ton fichier est beaucoup plus gros et un bon hachage ne permet pas de connaître la taille du fichier. Casser un hashage MD5 (un des meilleurs) et du domaine du possible en dessous de 50 lettres a-z et A-Z(et encore, ça prendra déjà pas mal de temps... quelques années quoi ^^). Au dessus, c'est temporellement impossible. Le fichier étant plus gros que la clef... tu as compris ;-)Conclusion : il vaut mieux hasher le fichier plutôt que la clef si tu veux vérifier l'intégrité.
Les vraiment bons algos : DES, RSALes algos plus abordables : XOR, VigenèreLes mauvais : César, César et César ^^Il y en a beaucoup d'autres bien sûr, mais il est 23:10, on est le premier janvier donc je me souviens de ceux-là ^^Si ça t'intéresses, tu peux toujours chercher des cours sur la cryptologie avec google (et oui, google est ton ami).
euhm, le coup du hashage, on en a déjà parlé plus haut.quant à "casser" un hashage comme tu dis, le terme est faux: on casse un cryptage, mais on "reverse" un hashage. je sais pas comment on dit en français.et techniquement, le md5 est sur 16 octets, donc a priori au delà de 16 caractères, en supposant que la répartition est uniforme bla bla bla, je pense que c'est tout à fait safe!mtnt, si tu hash un mot de 7 lettres, bah mettre le hashage triple la taille du fichier et c'est plus facile de reverser le hashage que de casser le message crypté puisque la vérification de validité est automatique et certaine.
Tout dépend de l'utilisation que tu en as... Et des fichiers de 7octets, on est d'accord, ça cours pas les rues.
si tu veux crypter ton code de carte banquaire ... (ou bancaire plutôt ... je sais plus)
bancaire... On peut toujours imaginer un algorithme de création de bruit avant cryptage si le fichier est trop petit...
Le hachage c'est tres lourd comme opération pour une simple verification, meme si cela n'affecterai en rien la protection du logiciel, il est facil aujourdhui de realiser des fichiers differents qui ont le meme hash MD5 et SHA(kk soit leur taille). Je soutient donc Kirua qui a totalement raison, une verification de "la bonne clef" est totalement inutil.Le RSA est une excellente securité, si tu utilise une clef suffisamment longue et bien construite(car une clef male construite de 700 bits peu se casser en kk minutes), l'inconvenient c'estque c'est un cryptage extremement lent sur de gros fichiers du fait de la taille de la clef.Le DES ou plustot (DES commence a vieillir) prenons le TDES/AES sont vraiments de bon algos, sures et rapides.Et derniere petite note: L'authentification d'une carte bancaire est protegee par RSA-768 bits et pour des operations directes avec la banque par une encryption TDES en ligne.
Merci pour les infos. C'est clair que le hachage est lent, mais je proposait ça si vraiment on veut ou doit vérifier l'intégrité du fichier... Personnellement je ne vérifie jamais. C'est selon moi la façon de faire la plus safe et c'est cela que je voulais exprimer.Réaliser des fichiers qui ont la même clef... Es-tu sûr que ce soit si simple ? Quoi qu'il en soit, pour la vérification, je pense que cela deviennte difficile de créer une clef qui donnera un fichier décrypté ayant le même hash...
un petit tour par ici :)http://eprint.iacr.org/2004/199.pdf
Je m'incline. Je lirai ça en détail après mes examens :-S
Quelle est l'objection? tu dis qu'on peut créer deux fichiers qui ont le même hash ... Et? Ça veut dire qu'il existe une chance sur l'infini que si l'utilisateur tape la mauvaise clé le fichier produit ait la même signature et soit considéré comme correct: rien à fiche.Et puis, ton argument: c'est lent et lourd le hashage pour une simple comparaison ... mais ça a été inventé POUR ça! POUR faire des comparaisons rapidemment et sans avoir besoin des infos de départ. Comparer le hashage d'un fichier d'un Giga après l'avoir téléchargé avec le hashage originale, ça va qd même 'achement plus vite que de le télécharger deux fois et de comparer les deux, pas vrai?Et encore: c'est lent sur des gros fichiers ... sur un gros fichier, tout est lent, c'est pas pour objecter, mais c'est un peu facile ^_^. Et qd on parle de sécurité, je vois pas le souci... Quoi qu'il en soit, une implémentation personnelle d'un algo réputé inviolable sera le plus souvent mal faite et donc tout simplement naïvement sécurisée. Se sentir protégé peut amener un comportement irresponsable, alors que de réels cryptanalystes seront capables de casser le code. Tu le dis toi-même: si les clef sont mal choisies ...
> Commentaire de : atifelkhachine le 31/12/2005 17:38:16Envoyer un message à atifelkhachine>et pour savoir si l'utilisateur a entré la bonne clé ou non ?>pour moi j met la somme des codes ascii de la clé ds le fichier ...>y a t il autre methode ?>fais le avec un modulo ça te permettra de dire direct si la clef est mauvaise (et que tu as un peu de chance)et pour le reste de ce qui est dit icion va dire que je suis d'accord mais modérez vos "impossible", simplement, c'est quasi infaisable en l'état actuelle de la techno.apres, on aura tjs le compromisvitesse/place & solidité du cryptage à résoudre...si vous voulez je peux vous en proposer un codage réversible tout simple:prenez le fichier en hexa et faites un rol ou un ror.d'1 à 7 bits.c'est cassable,évidemment,mais seulement si on a une idée sur le contenu et la méthode de cryptageMagicalementBonne annéeNono.
j'ai dit en hexa?en binaire biens sur....
rol ? ror ? Qu'est-ce que c'est ?
Kirua>Je disais que le hachage etait violent puisque l'auteur voulait integrer le hachage de la clef dans le fichier crypté et non pas le hachage du fichier d'origine.Ensuite je parlais de facon general sur les faiblesses des fonction hash quant à la verification de l'authenticité d'un fichier.Ensuite un implantation personnelle d'un algo n'a pas de raison d'être mauvaise si on sait de quoi on parle, que l'on se munit d'un minimum de renseignements...
"Ensuite un implantation personnelle d'un algo n'a pas de raison d'être mauvaise si on sait de quoi on parle, que l'on se munit d'un minimum de renseignements..."on dit implémentation, mais c'est pas ça le prob ;)regarde: tu apprends ce qu'est une intégrale propre définie à l'école. tout de suite tu te dis: numériquement, c'est fastoche de calculer les valeurs!alors ok: tu fais un algo qui additionne des trapèzes.ben c'est mauvais.tu te documents:tu fais un pas adaptatif, tu utilises euler plutôt que des trapèzes, puis même un runge kutta, tu lis des choses ci et là sur les maths des intégrales numériques.toujours mauvais.qu'est-ce qui ne va pas?le calcul numérique, c'est une compétence à part en informatique et algorithmique. tout le monde sait en faire un peu (comme tout le monde qui a fait de l'analyse sait faire un peu d'arithmétique, pour faire le parallèle), mais il y a bcp bcp de choses à prendre en compte qu'on ne soupçonne pas!dans le cas du calcul numérique, ok: tu lis "numerical recipes in C", tu as qq cours à l'unif ou dans ta haute école si tu fais de l'ingénierie ou quoi, t'auras ce qu'il faut pour faire une BONNE (qualité professionnelle) implémentation de ton algo de calcul numérique d'intégrales.Mais la crypto ... ça c'est avant tout un challenge mathématique poussé: je pense qu'on peut tous se convaincre de la solidité de RSA en s'appliquant à lire correctement les explications math. et en cherchant un minimum à s'impliquer, mais le fondement du pourquoi de l'algo, du comment, des subtilités qu'on ne te révèlera pas sur internet, ça: tu n'auras pas. Quant à l'implémentation algorithmique, je pense que c'est là que doivent se retrouver le plus de bêtises. Ça va commencer avec un générateur de nombres pseudo-aléatoires complètement con qui va faire boucler les clefs générées par ton logiciel. Puis ça va se passer dans des sauvegardes de paramètres absurdes qui révèleraient bcp à un cryptographe casseur de code. Et bien sûr toutes les petites subtilités: on ne les connait pas si on n'a pas eu de cours de crypto poussé, donc on ne peut pas produire un code qui en tient compte. Résultat: un pro peut démonter la chose: quelqu'un qui sait.
Kiru> rien a ajouté tu as bien résumé la choseDom> ror & rol : des décallages ex : ror(2,0011 1101) => 0100 1111en prenant le cas d'un ror sans perteroll on rightroll on left(google te dira si C la trad exacte, mais ça permet de comprendre)+
Ce programme est pas mal, même si il est vrai que c'est un algo assez facile à casser...Par contre comme il est dit plus haut, mettre des infos sur la clé (comme la somme des caractères ASCII par exemple) est assez dangereux... si ta clé est "clef" est que tu tapes "flec" au moment de décrypter et bien ton prog va quand meme decrypter avec succès le fichier... pas top non ?Mais ca reste un bon programme quand même :)
Se souvenir du profil
Mot de passe oublié ? / Activation de compteCréer un compte