CRIPTEUR DE FICHIER TEXTE QUI PROTEGE PAR MOT DE PASSE

ymca2003 Messages postés 2070 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 3 juillet 2006 - 8 mars 2005 à 18:05
 Utilisateur anonyme - 11 mars 2005 à 19:26
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/29986-cripteur-de-fichier-texte-qui-protege-par-mot-de-passe

Utilisateur anonyme
11 mars 2005 à 19:26
,-----------,
| lol |
'-----------'
cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
11 mars 2005 à 18:57
Dis donc quand on sait pas que les majuscules c'est seulement au début on se tait hein !
(humour pouris g pas pu m'en empêcher...)
Utilisateur anonyme
11 mars 2005 à 18:48
Bon, là par contre faut vraiment que je dise à malkommalkom que "cripter" ca s'écrit crypter.
Autre chose, c'est pas parce qu'un son se prononce "er" qu'il s'écrit forcément "er". En francais y'a des règles de conjugaison et de grammaire.

À quand www.orthofrance.com ???
Ou alors www.smsfrance.com ???
Utilisateur anonyme
11 mars 2005 à 18:43
Le plus rapide c'est ++i. Bon dans le cas des types de bases, le compilo doit bien faire ses optimisations...
Mais sinon, pense que quand on fait i = i+1, ca consulte i, ca ajoute 1 et ca enregistre i.
Quand on fait i++, ca sauvegarde la valeur de i, ca incrémente i de 1 (en un coup) et ca renvoie la valeur sauvegardée.
++i ca incrémente i de 1 et ca le renvoie.

C'est surtout vrai avec les objets, lorsque l'on crée des types abstraits. Sinon, pour les types de bases, ca dépend vraiment des architectures de proc (je crois que ce que j'ai dis est valide sur les processeurs RISK car les opérations qui incrémentent directement en mémoire existent; mais c'est à vérifier...).

=> Brunews: je pense que même si malkommalkom n'y est pas parvenu, il a au moins éssayé de faire qque chose, et même ce genre de programmes peut aider qqun (dont lui).
cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
11 mars 2005 à 18:39
Et pour finir (après j'arrête promis ;-)) je viens d'ouvrir le fichier crypté... J'ai tout de suite trouvé la méthode de cryptage sans avoir lu ton code... C'est pas bête mais très facile à casser...
Un petit conseil : mélange ! Si tu mélange en fonction de la clé, ça devient déjà plus difficile à casser, vu qu'on ne connait pas la place originale... Et en plus tu ne dois plus écrire la clé dans le fichier (enfin ça on te l'a déjà dit c'est très mauvais).
Bon ça ne vaudra jamais RSA hein je suppose que tu en est conscient, mais je trouve ça marrant.

Voilà cette fois je me tais en tout cas bonne continuation ;-).
cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
11 mars 2005 à 18:28
Et un autre truc : quand tu publie pense à commenter ton code... Bon ici c'est vrai c'est pas impossible de lire sans mais c'est toujours plus facile ;-)
cs_dominion Messages postés 230 Date d'inscription mardi 21 janvier 2003 Statut Membre Dernière intervention 15 mai 2008
11 mars 2005 à 18:26
Bon perso je n'ai pas lu le code en lui-même j'ai juste parcouru et un truc m'a sauté aux yeux (deux en fait mais l'ortho on va pas en parler ;-)) :

Tu écris i = i+1;
Écris plutôt i++; voire ++i; (c'est la même chose dans ton cas). Ne me demande pas pourquoi mais il paraît que c'est plus rapide... Je pense connaître la raison, mais faute d'être sûr, je préfère ne pas polluer ce topic... Si quelqu'un sait nous éclairer...
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
11 mars 2005 à 13:45
fgets et cout, on en a déjà bien assez sur cppfrance, hormis cela il ne me parait pas y avoir grand chose d'intéressant ici, voila tout.
La raison d'une source doit être d'apporter quelque chose à ceux qui la liront.
Utilisateur anonyme
11 mars 2005 à 13:31
Brunews, j'aimerais que tu sois plus clair, je ne comprend pas ce que tu veux dire par "Par contre on attend un peu plus intéressant pour la suite, je ne conserverai pas d'autres sources aussi "utiles" par la suite". Pourrais tu être plus clair ?
Utilisateur anonyme
11 mars 2005 à 13:29
Non ce n'est pas vrai du tout.
Crypter un document en AES et joindre un hashage de la clé ne compromet en rien le secret, pourvu que le hashage soit fiable (utiliser MD5 ou SHA1).
Ce programme ne se casse pas en qques minutes. J'ai bien signalé à malkommalkom que son cryptage devait dépendre de la clé entrée.

D'ailleurs certains crypto-systèmes utilisent ce système, surtout lorsque l'algorithme est lent.
De toute façon, il faut bien intégrer dans tout crypto système une façon d'être sûr que le message décrypté soit le bon. S'en est une parmis d'autres.
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
11 mars 2005 à 00:54
malkommalkom > Kirua a dit ce qu'il y avait à dire donc je n'en rajouterai pas. Par contre on attend un peu plus intéressant pour la suite, je ne conserverai pas d'autres sources aussi "utiles" par la suite, on manque déjà de place sur le serveur.

Bonne continuation.
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
10 mars 2005 à 23:06
Ça sert à rien de faire une vérif du style: il a le bon passe, ok on lance le décodage (c'est pas du décryptage s'il y a pas de clef). Ce genre de programme se casse en qq minutes avec un désassembleur. Suffit de repérer la conditionnelle (if c'est le non passe) et de la sauter avec un jmp ou je sais pas tout quoi que les cracker utilisent en asm. Sécurité 0 ... puis comme je disais: si révéler l'algo = désécuriser les contenus, alors ça vaut pas tripette, dsl :/ une simple permutation d'alphabet fait déjà mieux.
Utilisateur anonyme
10 mars 2005 à 22:54
Amusant comme prog. Bon c'est vrai qu'il y'a un peu de boulot, mais c'est intéressant. Faudrait au moins que le passe serve à quelque chose et qu'il soit pas stocké en clair dans le fichier (hash pour ceux qui connaissent).
Comme ca tu vérifie si le pass est bon et après tu décode le texte. Ca évite de décoder si le passe est pas correct.
En tout qu'à, l'orthografe c'et pas ton truk ;-)
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
9 mars 2005 à 07:49
Dis, pour ce qui est du cryptage, dis-toi bien ceci:

une méthode de cryptage ne commence à être valable que lorsque, même si l'on en publie l'algo, les fichiers cryptés avec ce dernier ne sont pas compromis.

Dans ton cas, avoir le programme = pouvoir tout "décrypter" (sauf que ce que tu fais ces, techniquement parlant, de l'encodage, puisque la clé n'intervient pas dans le processus).
malkommalkom Messages postés 36 Date d'inscription mercredi 1 novembre 2000 Statut Membre Dernière intervention 7 novembre 2010
8 mars 2005 à 21:38
Je ne le prend pas mal, au contraire les critiques me permettent de corriger ma prog.
Justement ou je mélende le c et c++ dans mes E/S stp?
ymca2003 Messages postés 2070 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 3 juillet 2006 7
8 mars 2005 à 18:05
Le prend pas mal mais ton cripteur ne sert à rien pour les raisons suivantes :
- tu stocke le mot de passe dans le fichier cripté.
- tu n'utilise pas le mot de passe pour cripter le fichier (peut importe le mot de passe que tu donne, le fichier cripté sera le même).

Non seulement le criptage est trop simple (addition d'un offset à chaque carcactères) mais en plus il n'y a pas besoin de connaître le mot de passe pour récupérer le fichier original (il suffit de modifier le code du prog et de virer le test de validité du mot de passe).

Ensuite niveau code :
- tu mélange le C et le C++ pour les E/S, fait un choix.
- tu inclus un .c dans un fichier source, pas bon comme technique.
Rejoignez-nous