CRYPTOR

Commentaire de le_duche le 31/12/2005 08:56:34

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...

Commentaire de dominion le 31/12/2005 12:14:06

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 !

Commentaire de atifelkhachine le 31/12/2005 16:50:35

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é.

Commentaire de Kirua le 31/12/2005 16:58:43

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.

Commentaire de Kirua le 31/12/2005 17:29:03

RSA :D

Commentaire de Kirua le 01/01/2006 14:05:56

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.

Commentaire de Kirua le 01/01/2006 22:54:34

"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.

Commentaire de dominion le 01/01/2006 23:08:28

Les vraiment bons algos : DES, RSA
Les algos plus abordables : XOR, Vigenère
Les 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).

Commentaire de dominion le 01/01/2006 23:15:50

Tout dépend de l'utilisation que tu en as... Et des fichiers de 7octets, on est d'accord, ça cours pas les rues.

Commentaire de dominion le 01/01/2006 23:20:46

bancaire... On peut toujours imaginer un algorithme de création de bruit avant cryptage si le fichier est trop petit...

Commentaire de dominion le 02/01/2006 13:16:42

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...

Commentaire de dominion le 02/01/2006 15:10:07

Je m'incline. Je lirai ça en détail après mes examens :-S

Commentaire de magic_Nono le 05/01/2006 16:20:34

>    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 ici
on 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 compromis
vitesse/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 cryptage



Magicalement
Bonne année
Nono.

Commentaire de dominion le 05/01/2006 16:33:45

rol ? ror ? Qu'est-ce que c'est ?

Commentaire de Kirua le 05/01/2006 22:13:21

"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.

Commentaire de couleur78 le 10/04/2006 17:44:09

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 :)