CRYPTOR

marcusmavita Messages postés 1 Date d'inscription lundi 4 février 2013 Statut Membre Dernière intervention 4 février 2013
4 févr. 2013 à 11:18

je vient d'arriver mais pour moi je doit essaie d'abord son fonctionnement avant de juge

couleur78 Messages postés 3 Date d'inscription mercredi 28 septembre 2005 Statut Membre Dernière intervention 6 mars 2007
10 avril 2006 à 17:44

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

magic_Nono Messages postés 1878 Date d'inscription jeudi 16 octobre 2003 Statut Membre Dernière intervention 16 mars 2011
6 janv. 2006 à 02:19

Kiru> rien a ajouté tu as bien résumé la chose

Dom> ror & rol : des décallages

ex : ror(2,0011 1101) => 0100 1111

en prenant le cas d'un ror sans perte
roll on right
roll on left
(google te dira si C la trad exacte, mais ça permet de comprendre)
+

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
5 janv. 2006 à 22:13

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

oBsEC Messages postés 14 Date d'inscription mardi 17 juin 2003 Statut Membre Dernière intervention 29 juin 2006
5 janv. 2006 à 18:20

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

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
5 janv. 2006 à 16:33

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

magic_Nono Messages postés 1878 Date d'inscription jeudi 16 octobre 2003 Statut Membre Dernière intervention 16 mars 2011
5 janv. 2006 à 16:23

j'ai dit en hexa?
en binaire biens sur....

magic_Nono Messages postés 1878 Date d'inscription jeudi 16 octobre 2003 Statut Membre Dernière intervention 16 mars 2011
5 janv. 2006 à 16:20

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

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
5 janv. 2006 à 00:16

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

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
2 janv. 2006 à 15:10

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

oBsEC Messages postés 14 Date d'inscription mardi 17 juin 2003 Statut Membre Dernière intervention 29 juin 2006
2 janv. 2006 à 14:26

un petit tour par ici :)
http://eprint.iacr.org/2004/199.pdf

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
2 janv. 2006 à 13:16

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

oBsEC Messages postés 14 Date d'inscription mardi 17 juin 2003 Statut Membre Dernière intervention 29 juin 2006
2 janv. 2006 à 12:27

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.

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
1 janv. 2006 à 23:20

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

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
1 janv. 2006 à 23:17

si tu veux crypter ton code de carte banquaire ... (ou bancaire plutôt ... je sais plus)

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
1 janv. 2006 à 23:15

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

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
1 janv. 2006 à 23:10

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.

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
1 janv. 2006 à 23:08

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

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
1 janv. 2006 à 23:00

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

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
1 janv. 2006 à 22:54

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

atifelkhachine Messages postés 43 Date d'inscription samedi 29 mars 2003 Statut Membre Dernière intervention 1 janvier 2008
1 janv. 2006 à 19:39

wé.mais ca serai bien de savoir si le ga a entrer la bonne clé ou non ...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
1 janv. 2006 à 14:05

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.

atifelkhachine Messages postés 43 Date d'inscription samedi 29 mars 2003 Statut Membre Dernière intervention 1 janvier 2008
31 déc. 2005 à 17:38

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 ?

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
31 déc. 2005 à 17:29

RSA :D

atifelkhachine Messages postés 43 Date d'inscription samedi 29 mars 2003 Statut Membre Dernière intervention 1 janvier 2008
31 déc. 2005 à 17:06

sinon.ya t il un bon algo de cryptage ?

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
31 déc. 2005 à 16:58

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.

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
31 déc. 2005 à 16:53

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

atifelkhachine Messages postés 43 Date d'inscription samedi 29 mars 2003 Statut Membre Dernière intervention 1 janvier 2008
31 déc. 2005 à 16:50

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

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
31 déc. 2005 à 12:59

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

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
31 déc. 2005 à 12:14

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 !

cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
31 déc. 2005 à 11:55

Tu crypte selon quel algorithme ?

le_duche Messages postés 159 Date d'inscription lundi 13 juin 2005 Statut Membre Dernière intervention 26 février 2009
31 déc. 2005 à 08:56

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

Votre réponse