Discussion :

[droliprane]

Bonjour à tous

je développe un petit programme qui me permet de crypter un fichier txt, édité dans une zone de texte.

Je stock le hash md5 de la clé de cryptage/décryptage dans une clé de registre du système

Voici le scénario qui pose problème :

1) Première utilisation du programme, il me demande de définir la clé de cryptage, laquelle est sauvegardée dans le registre, comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
bufHash est une chaîne = HashChaîne(HA_MD5_128,SAI_cle)
RegistreEcrit("HKEY_CURRENT_USER\Software\Mon Appli", "key", bufHash)

2) J'édite un fichier vierge et je le crypte pour la première fois:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
fCrypte(chemin_fichier, chemin_fichier_temp,key,crypteSécurisé,encodeBASE64)
fCopieFichier(chemin_fichier_temp, chemin_fichier)

3) Je fais exprès de supprimer la clé dans la base de registre, et je relance mon programme, qui ne trouve pas la clé de cryptage dans le registre et me demande donc d'en définir une nouvelle (comme si j'utilisais le programme pour la première fois)
Je saisis la même clé de cryptage qu'en 1), j'ai comparé dans le registre j'ai bien le même hash md5 (en tout cas visuellement)

4) Je rouvre mon programme, il me demande la clé de décryptage, je la saisis, elle est comparée au hash dans le registre, c'est tout bon sinon j'aurais un message d'erreur me disant que la clé est incorrecte

5) C'est là que ça ne va plus, le programme n'arrive pas à décrypter mon fichier, pourtant bien crypté précédemment avec la même clé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fDécrypte(chemin_fichier,chemin_fichier_temp,key,crypteSécurisé,encodeBASE64)

Je ne suis pas forcément très calé en encryptage, peut-être que j'ai raté quelque chose.

En fait mon programme fonctionne super bien tant que je ne change pas la clé de registre : j'édite le fichier texte, je le crypte, je le rouvre, je le modifie, je le recrypte, parfait ça fonctionne bien..... du moins tant que je ne supprime pas la clé de registre et que je la recréée, même à l'identique

Ce qui m'empêcherai par exemple de pouvoir copier mon fichier texte sur une autre machine, définir la clé de décryptage dans le registre, et espérer pouvoir décrypter le fichier txt

A noter que si je rentre la clé de cryptage en dur dans mon programme ça fonctionne impécable, mais l'intérêt de sauvegarder le hash dans la base de registre et de pouvoir changer la clé de temps en temps....

Auriez-vous une idée svp ?

[frenchsting]

Initialement, je t'aurais dit que c'est un pb de caractères imprimables. Mais là, c'est une colle.

Il te retrouve bien ta clé dans la base de registre ? Je suppose que tu as fait du pas à pas et du test à tour de bras...

[tatayo]

Bonjour,
Deux chaines distinctes peuvent très bien avoir le même hash md5, et un hash md5 peut contenir des caractères non imprimables.
Donc est-ce que tu es absolument certain que les deux clés sont identiques ?

A part vérifier la clé, à quoi sert précisément ce hash ? Est-ce qu'il intervient dans le cryptage/décryptage ?

Tatayo.

[Hemgé]

Bonjour,

Pas d'idée précise, mais une proposition.

Je suppose que vous utilisez HashChaîne() et HashVérifieChaîne() ?
Alors vous devriez abandonner MD5, qui n'est plus jugé fiable à l'heure actuelle, et adopter plutôt un des SHA, qui sont beaucoup plus solides.
WD propose encore d'autres types, mais le choix des plateformes est alors plus limité.

Avec les SHA, le risque de doublon évoqué par tatayo disparaîtra totalement (sauf erreur de ma part, car je ne suis pas spécialiste).

Hemgé

[dsr57]

Bonjour,

Pour moi si les tests sans suppression et cle en dur sont ok je verifierais la lecture et écriture dans la base de registre.

Bon dev

[michel.souris]

Ne s'agit-il pas d'un problème de conversion ANSI/UNICODE ?

[droliprane]

Bonjour,

désolé de pas avoir répondu plus tôt, je n'avais pas d'informatique à portée

Le bug a été résolu en réalisant le hash en SHA512 et non plus MD5_128

Possiblement lié à ma vieille version .... ?

[DelphiManiac]

...
Avec les SHA, le risque de doublon évoqué par tatayo disparaîtra totalement (sauf erreur de ma part, car je ne suis pas spécialiste).
Hemgé

Un hash, quelque soit le type de hash, à toujours un risque de collision. S'il n'y avait aucun risque de collision, cela indiquerait que chaque valeur, quelque que soit sa taille (4go de données par exemple) pourrait être réduite à un hash unique, ce qui s'apparenterait à de la compression très efficace :p