PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → BUG CrypteStandard()
BUG CrypteStandard()
Débuté par Simon, 19 mar. 2018 12:46 - 6 réponses
Posté le 19 mars 2018 - 12:46
Bonjour à toutes et à tous,

J'utilise depuis peu la fonction CrypteStandard() en AES128 avec une clé fixée par un HashChaîne et j'ai bien pris soin de respecter la doc PC Soft et de la suivre à la lettre

gsCryptageMDP est une chaîne = ChaîneVersUTF8("MonMdp")
gbufCryptageCle est un Buffer = HashChaîne(HA_MD5_128, gsCryptageMDP)


J'appelle ensuite une fonction pour mon cryptage en passant comme paramètre mon champ texte converti en buffer et préalablement passé par ChaîneVersUTF8()

FONCTION FG_CryptageGet_buf(pbufEntree est un Buffer)

bufSortie est un Buffer

bufSortie = DécrypteStandard(pbufEntree, gmodPhoenix.gbufCryptageCle, crypteAES128)

RENVOYER bufSortie



FONCTION FG_CryptageSet_buf(pbufEntree est un Buffer)

bufSortie est un Buffer

bufSortie = CrypteStandard(pbufEntree, gmodPhoenix.gbufCryptageCle, crypteAES128)

RENVOYER bufSortie



La fonction CrypteStandard() fonctionne très bien jusqu'à ce que de manière aléatoire le buffer contienne des RC, des espaces ou autres caractères exotiques générés par la fonction CrypteStandard().

Du coup le buffer de sortie est tronqué et le stockage de la donnée cryptée également, que ce soit dans un .ini ou dans un .fic
Forcément au décryptage la fonction renvoie une belle erreur car elle ne reçoit pas le nombre de caractères attendus lorsque le buffer initial a été massacré par la fonction CrypteStandard() !


Bug reproduit sur l'exemple unitaire "Les fonctions Crypte" et erreur fatale identique !!!

Si quelqu'un a une solution je suis preneur, merci par avance pour un petit coup de pouce ^^
Posté le 19 mars 2018 - 14:57
Illustration du bug RC sur l'exemple fourni avec WD :



Posté le 21 mars 2018 - 19:48
Un petit up.

Quelqu'un arrive t'il à reproduire le bug dans l'exemple fonction crypte livré avec WD ?
Le support technique étant incapable de donner une suite et ne repondant même plus, j'en appelle à la communauté s'il vous plaît.
Membre enregistré
2 571 messages
Popularité : +222 (260 votes)
Posté le 22 mars 2018 - 04:18
Bonjour,

Perso aucun problème.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membre enregistré
282 messages
Popularité : +1 (1 vote)
Posté le 22 mars 2018 - 09:22
Bonjour,
c'est en Windev23 ? En 22, je n'ai pas de problème.

--
Christophe Charron
Posté le 22 mars 2018 - 10:32
Bonjour

Il n'y a pas de bug et le problème de l'exemple est également présent en version 22.

En fait ce problème vient du fait que le texte crypté est affecté à un champ texte et que l'on repart de ce champ texte pour le décryptage.
Ce qui se passe c'est que le contenu du buffer est transformé lors de l'affectation au champ de saisie (passage du type buffer au type chaine). Les caractères 0x0a sont transformés en RC (0x0d 0x0a), les caractères 0x00 sont interprétés comme des fins de chaines...

Si vous modifiez l'exemple pour travailler uniquement avec des variables de type buffer pour le cryptage/décryptage alors vous n'aurez plus de problème.

Bon dev.

Laurent M.
Posté le 23 mars 2018 - 11:54
Bonjour Laurent et merci pour votre réponse.

En effet si je travaille uniquement avec des variables et en faisant des conversions HexaVersBuffer() et BufferVersHexa() cela fonctionne.

Je peux donc stocker mon buffer crypté dans un .ini et en hexa pour ne pas rencontrer ce problème de RC.
Il faut également bien faire attention à l'encodage des chaînes selon la techno utilisée.

Merci pour ton éclaircissement.