IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

WinDev Discussion :

fonctionnement de fcrypte/fdecrypte, unicité du résultat ? [WD17]


Sujet :

WinDev

  1. #1
    Membre averti Avatar de droliprane
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2005
    Messages
    682
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2005
    Messages : 682
    Points : 387
    Points
    387
    Par défaut fonctionnement de fcrypte/fdecrypte, unicité du résultat ?
    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 ?
    'Diviser chacune des difficultés en autant de parcelles qu’il se pourrait et qu’il serait requis pour les mieux résoudre', René Descartes

    => Maya GPAO

  2. #2
    Expert éminent
    Avatar de frenchsting
    Homme Profil pro
    mutlitâche-multifonction
    Inscrit en
    juin 2003
    Messages
    4 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : mutlitâche-multifonction
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2003
    Messages : 4 257
    Points : 7 294
    Points
    7 294
    Par défaut
    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...
    Commencez toujours appuyer sur la touche F1 et puis n'hésitez à passer par un moteur de recherche...
    Le forum est fait pour répondre aux questions : pas la peine de me les envoyer par MP. Merci.

    Make it real not fantasy.

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 721
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 721
    Points : 11 346
    Points
    11 346
    Par défaut
    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.

  4. #4
    Membre émérite
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    1 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 075
    Points : 2 439
    Points
    2 439
    Par défaut
    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é

  5. #5
    Rédacteur/Modérateur

    Avatar de dsr57
    Homme Profil pro
    Analyste programmeur senior
    Inscrit en
    octobre 2003
    Messages
    1 139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Analyste programmeur senior
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2003
    Messages : 1 139
    Points : 4 807
    Points
    4 807
    Billets dans le blog
    22
    Par défaut
    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
    ------------------------------------------------------------------------------------------------------------------------------------------
    Mon message vous a aidé, pensez à remercier . La discussion est résolue, n'oubliez pas le tag
    ------------------------------------------------------------------------------------------------------------------------------------------
    Site perso : Formation, Expérience, Réalisations, ...
    Blog : Le Blog de DSR57 - Programmation WinDev

  6. #6
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2009
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2009
    Messages : 1 278
    Points : 2 151
    Points
    2 151
    Par défaut
    Ne s'agit-il pas d'un problème de conversion ANSI/UNICODE ?
    SQL : le véritable Esperanto

    "Les patates à ta tata épatent ton tonton mais les pates aux thons à ton tonton épatent pas ta tata." (Michel Souris)

    MERCI DE NE PAS M'ENVOYER DE MESSAGE PRIVE POUR DES QUESTIONS TECHNIQUES SANS MON ACCORD !

  7. #7
    Membre averti Avatar de droliprane
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2005
    Messages
    682
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2005
    Messages : 682
    Points : 387
    Points
    387
    Par défaut
    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 .... ?
    'Diviser chacune des difficultés en autant de parcelles qu’il se pourrait et qu’il serait requis pour les mieux résoudre', René Descartes

    => Maya GPAO

  8. #8
    Membre émérite
    Avatar de DelphiManiac
    Homme Profil pro
    Homme à tout faire
    Inscrit en
    mars 2002
    Messages
    1 132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Homme à tout faire
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2002
    Messages : 1 132
    Points : 2 479
    Points
    2 479
    Par défaut
    Citation Envoyé par Hemgé Voir le message
    ...
    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
    Si ce message vous a semblé utile, il est possible qu'il soit utile à d'autres personnes. Pensez au . Et n'oubliez pas le le moment venu !

    On n'a pas à choisir si l'on est pour ou contre la décroissance, elle est inéluctable, elle arrivera qu'on le veuille ou non.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 11
    Dernier message: 09/06/2010, 16h06
  2. Réponses: 3
    Dernier message: 09/02/2010, 21h15
  3. Réponses: 3
    Dernier message: 28/08/2009, 14h30
  4. [SQL] Unicité d'un champ de résultat portant le même nom
    Par lodan dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 09/11/2006, 12h39
  5. Réponses: 4
    Dernier message: 26/05/2006, 09h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo