PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WEBDEV 2024 → Problème avec DecrypteStandard
Problème avec DecrypteStandard
Débuté par Philippe SB, 02 aoû. 2016 13:10 - 22 réponses
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 02 août 2016 - 13:10
Bonjour,

J'ai un webservice développé en webdev. Je tente d'envoyer des données cryptées par une application faite en windev mobile. Après 2 jours de tests divers et variés, j'ai réussi à transférer mes données cryptées. Cependant lorsque je tente de les décrypter, j'obtiens l'erreur suivante.

Quelqu'un a-t-il une idée ?

"La phase de finalisation de l'algorithme de cryptage/décryptage a échoué"

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membre enregistré
3 messages
Posté le 26 novembre 2016 - 11:54
Bonjour,
J'ai le même problème.
Avez vous obtenu une réponse ou trouvé une solution ?

J'ai utilisé l'exemple Utilisation des fonctions de cryptage et mon enveloppe Xml plante lors du décryptage avec l'erreur
Appel WL :
Traitement de 'Procédure locale Decryptebuffer' (FEN_Cryptage.PROCEDURE.Decryptebuffer), ligne 19, thread 0
Fonction 'DécrypteStandard', syntaxe 3

Que s'est-il passé ?
Le décryptage du message a échoué.
La phase de finalisation de l'agorithme de cryptage/décryptage a échoué.

Code erreur : 101750
Niveau : erreur non fatale

Dump de l'erreur du module 'wd210com.dll' (21.0.58.0).
Identifiant des informations détaillées (.err) : 101750
Informations de débogage :
Fonction (10,423)
Informations supplémentaires :
EIT_PILEWL :
Procédure locale Decryptebuffer (FEN_Cryptage.PROCEDURE.Decryptebuffer), ligne 19
Clic sur BTN_DECRYPTE (FEN_Cryptage.BTN_DECRYPTE), ligne 8
EIT_DATEHEURE : 26/11/2016 11:37:53
EIT_TYPE_WDFILE : <2>
EIT_IDCODE : <458752>


L'aide ne documente aucun cas d'erreur.

Cordialement.

SLEV
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 26 novembre 2016 - 20:20
Bonjour,

Le problème vient vraisemblablement d'un problème de codage de caractère unicode et ansi. Je te conseille de passer par des chaines utf8.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Posté le 19 mars 2019 - 17:18
Bonjour. Avez vous trouvés une solution à votre problem de décryptage de 2016?
Membre enregistré
9 messages
Popularité : +1 (1 vote)
Posté le 25 octobre 2019 - 16:06
Bonjour

J'ai le meme probleme sur android, et je ne sais pas comment faire
Membre enregistré
202 messages
Popularité : +6 (6 votes)
Posté le 27 mai 2020 - 14:20
Bonjour,

J'ai exactement le même soucis. Ca fonctionne sur windows et ça plante sur IOS.
L'application Windows est un projet unicode. La chaine que je décrypte est une chaine unicode.
J'ai créé un nouveau projet avec une configuration IOS, j'ai partagé l'analyse et la classe contenant la méthode de cryptage, et la classe avec la chaîne à décrypter.
Et en exécution sur IOS, j'obtiens ce message également, alors que je suis en unicode de bout en bout ...

Le code de décryptage est le suivant :
Procedure bufDecryptage(bufCrypté):Buffer
SI bufCrypté = "" ALORS RENVOYER ""
bufCle est un Buffer = HashChaîne(HA_MD5_128, ::MDP)
bufSRésultat est un Buffer = DécrypteStandard(bufCrypté, bufCle, crypteAES128)

RENVOYER bufSRésultat


Et le paramètre que je passe à la méthode est la valeur de la rubrique lue dans la BDD et est une chaine unicode.
Dans les 2 cas je passe par une connexion puis lecture en direct sur le serveur HFSQL.

Toute idée est la bienvenue!
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 27 mai 2020 - 16:05
Il faut passer le codage de caractère en utf8 des 2 côtés et on chiffre et déchiffre correctement

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
202 messages
Popularité : +6 (6 votes)
Posté le 27 mai 2020 - 18:59
Bonjour,

En effet, il restait une incohérence dans le cheminement de la chaîne cryptée, c'est le type de la rubrique dans la BDD. En changeant cette rubrique en mémo binaire (BLOB) le problème est réglé.

Merci.
Membre enregistré
202 messages
Popularité : +6 (6 votes)
Posté le 31 mai 2020 - 14:38
J'ai une question dérivée du sujet du coup. Maintenant, grâce aux conseils croisés de Philippe SB et de Fabrice H (depuis un autre ancien post), j'arrive à crypter et décrypter un mot de passe stocké en BDD dans un BLOB, que je sois sur n'importe quelle plateforme, super.
Du coup, je me suis souvenu que j'avais un soucis similaire mais pour un mot de passe que je sauvait dans un fichier XML (avec en-tête <?xml version="1.0" encoding="utf-8"?> et réellement bien encodé en UTF-8 :) ). Je reprend mes 2 méthodes adaptées, et ça ne va pas, le passage du mot de passe crypté dans le XML l'altère, voir, bousille le fichier. Est-ce donc possible ou pas d'écrire un mot de passe du genre 쉜砋齘䈢낣컹╏蘏泧첻緼硔⻱ dans un fichier xml?
Membre enregistré
1 143 messages
Popularité : +50 (142 votes)
Posté le 01 juin 2020 - 12:06
Bonjour
En le transformant en hexa (BufferVersHexa)

--
Thierry TILLIER
Développeur Windev-Webdev
Formation Windev : https://coursdinfo.teachable.com/
Formation bureautique : https://coursdinfo.net
Membre enregistré
202 messages
Popularité : +6 (6 votes)
Posté le 01 juin 2020 - 12:41
Mais c'est bien sûr!!!
Merci beaucoup Thierry, ça fonctionne parfaitement maintenant.
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 01 juin 2020 - 17:05
Perso je l'aurais encodé en base 64

--
Cordialement,

Philippe SAINT-BERTIN
Posté le 05 mars 2021 - 14:18
Bonjour à tous,

Je me permets de faire remonter ce sujet car j'ai un problème similaire, je pense que ma réponse est ici mais pourtant je tourne en rond. Le problème, donc :

Depuis mon application Windev, je dois chiffrer une chaîne de caractères puis l'enregistrer sur une BDD SQL hébergée en ligne. Plus tard dans mon traitement, je récupère ces données chiffrées depuis la BDD en ligne (encodage UTF8), et je dois les déchiffrer pour pouvoir les afficher à mes utilisateurs.
Mes données chiffrées sont stockées dans une colonne de type BLOB.
Si je chiffre puis déchiffre immédiatement mes données localement, aucun problème. En revanche si je veux déchiffre ce que j'ai récupéré depuis la BDD... ça ne fonctionne pas. Sauf si ma chaîne initiale contient uniquement des lettres. Dès qu'il y a des caractères spéciaux, le déchiffrement est impossible.

J'ai donc vraisemblablement un problème d'encodage... Qu'en pensez vous?
Philippe SB évoque le fait d'encoder en UTF8 des 2 côtés, j'ai donc essayé de faire un ChaîneVersUTF8() puis de chiffrer ma chaîne avec CrypteStandard() : mais là encore DecrypteStandard() ne fonctionne pas... Qu'est ce que je rate?

Merci d'avance pour votre aide!
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 05 mars 2021 - 19:17
Bonjour,

Il faudrait voir le code que tu as saisi pour te donner plus d'infos.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
1 143 messages
Popularité : +50 (142 votes)
Posté le 08 mars 2021 - 11:10
@Philippe : Dans vos posts je vois beaucoup de vos références avec un encodage en base 64, pourquoi préférez ce type d'encodage ? c'est par habitude ou bien avez-vous décelé un avantage par rapport aux conversions Hexa ? (pour ma culture :D)

--
Thierry TILLIER
Développeur Windev-Webdev
Formation Windev : https://coursdinfo.teachable.com/
Formation bureautique : https://coursdinfo.net
Tuto WINDEV sur ma chaîne Youtube
Posté le 08 mars 2021 - 11:54
@Philippe : Dans vos posts je vois beaucoup de vos références avec un
encodage en base 64, pourquoi préférez ce type d'encodage ? c'est par
habitude ou bien avez-vous décelé un avantage par rapport aux conversions
Hexa ? (pour ma culture :D)


je ne veux pas répondre pour Philippe, mais à priori c'est une "bonne
pratique"
car nous sommes actuellement sur une problématique de chiffrement avec
un système de visio; et eux aussi passent par du base64

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 08 mars 2021 - 12:48
EN effet l'encodage en base 64 fait partie des bonnes pratiques et a aussi certains avantages, tous les caractères sont imprimables, est compatible avec tous les systèmes et est énormément utilisé.

Une différence par rapport à l'hexadecimal c'est le poids en octets de la chaine générée qui est de l'ordre de 70 % moins importante en base 64.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
1 143 messages
Popularité : +50 (142 votes)
Posté le 08 mars 2021 - 13:47
Merci pour cet éclairage.

--
Thierry TILLIER
Développeur Windev-Webdev
Formation Windev : https://coursdinfo.teachable.com/
Formation bureautique : https://coursdinfo.net
Tuto WINDEV sur ma chaîne Youtube
Membre enregistré
21 messages
Popularité : +2 (2 votes)
Posté le 09 mars 2021 - 10:08
Bonjour à tous,

Après de nombreux tâtonnement j'ai fini par mettre en place les 2 procédures qui marchent sur Android, iOS, Linux, Windows, WebDev, WinDev. C'est très bœuf et pas efficace mais cela marche. Je déconseille fortement l'usage d'UTF-8 ou d'UNICODE. Forcer le passage en ANSI base 64 y que cela de vrais... J'utilise CRC de mon cru (celui des trames Ethernet 32-bits) car les CRCs communs à toutes les plateformes sont rares et représentent beaucoup de bytes par rapport à la longueur de message si celui-ci est court.

Bien cordialement,
marc

// Résumé : Décode Encoded_s64 avec la clé Key_Uk et place le résultat dans Decoded_s
Procedure UID256_Decode_b( LOCAL Encoded_s64 is ANSI string, // Valeur à décrypter (base 64)
LOCAL Key_Uk is 256-bit UUID, // Clés de décodage
Decoded_s is ANSI string = "") // Valeur décryptée (base 64)
// De temps à autre Décode (Encoded_s64) se passe mal
WHEN EXCEPTION IN
// Extrait les données à décrypter de la base 64
Crypt_m is Buffer = Decode (Encoded_s64)
Prv_h is Buffer = Key_Uk
// Decode les données HASH+DATA
Pack_m is Buffer = DecryptStandard ( Crypt_m , Prv_h , cryptAES256 )
DO
IF Log_1_bc THEN _Log_ts(["! DEC","Key_Uk",Key_Uk,"Encoded_s64",Encoded_s64])
// Produit un vecteur de test
Decoded_s = "";RESULT False
END
// Calcule le HASH des données
Pack_s is ANSI string = Pack_m
// UNPACK les données décryptées
CRC_Got_s is ANSI string = Pack_s[1 TO 8]
Data_Got_s is ANSI string = Pack_s[9 TO Length(Pack_s)]
// Calcule le HASH des données décryptées
CRC_s is ANSI string = UID_CRC_s64(Data_Got_s)
IF CRC_Got_s<>CRC_s THEN
IF Log_0_bc THEN _Log_ts(["- DEC",Key_Uk,"Blur",Length(Encoded_s64),_Short_s(Encoded_s64,16)])
Decoded_s = "";RESULT False
ELSE
// Tout va bien le HASK envoyé et le HASH calculé à partir des données décryptées sont identiques
IF Log_0_bc THEN _Log_ts(["+ DEC",Key_Uk,"Blur",Length(Encoded_s64),_Short_s(Encoded_s64,16)])
Decoded_s = Data_Got_s;RESULT True
END
CAS ERREUR:
IF Log_0_bc THEN _Log_ts(["! DEC",Key_Uk,"Blur",Length(Encoded_s64),_Short_s(Encoded_s64,16)])
Decoded_s = "";RESULT False

Procedure UID256_Encode_s64( LOCAL Clear_s is ANSI string,
LOCAL Key_Uk is 256-bit UUID)
// A conserver pour faciliter le debug
// RESULT Encode(Clear_s,encodeBASE64SansRC)

// Signe le message à encrypter
CRC_s is ANSI string = UID_CRC_s64(Clear_s)
// Assemble HASH et MSG
s is ANSI string = IntToHexa(UID_CRC_i(Clear_s))+Clear_s
Pack_m is Buffer = s
Prv_h is Buffer = Key_Uk
WHEN EXCEPTION IN
Encoded_s64 is ANSI string=Encode(EncryptStandard(Pack_m, Prv_h, cryptAES256),encodeBASE64SansRC)
IF Log_0_bc THEN _Log_ts(["+ ENCODE",Key_Uk,"Blur",Length(Encoded_s64),_Short_s(Encoded_s64,16)])
RESULT Encoded_s64
DO
// Produit un vecteur de test
RESULT ""
END
CAS ERREUR:
RESULT ""
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 10 mars 2021 - 09:37
Je déconseille fortement l'usage d'UTF-8 ou d'UNICODE. Forcer le passage en ANSI base 64 y que cela de vrais


Je ne suis absolument pas d'accord avec toi. L'utf8 est le seul encodage compatible avec tous les systèmes et si tu as bien codé ta chaine tu peux la décoder de n'importe où. L'utf-8 est d'ailleurs l'encodage standard sur le web et si c'est ainsi c'est qu'il doit y avoir une raison, sinon ils auraient tout passé en ANSI...

L'unicode par contre est effectivement à fuir comme la peste pour le transfert d'information inter-système car pas codé de la même manière sur toutes les plateformes.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
5 messages
Posté le 10 mars 2021 - 14:40
Je viens de voir vos réponses, j'ai trouvé la solution à mon problème le lendemain de mon post.

Je poste ma solution, si jamais cela peut servir à d'autres :
Après avoir chiffré mes données et avant de les enregistrer sur ma BDD en ligne, je dois encoder ma chaîne chiffrée en base64URL (base64 et base64sansRC ne fonctionnaient pas).
Et à l'inverse, lorsque je veux récupérer des données depuis ma BDD, je décode la chaîne avec le même type d'encodage avant de la déchiffrer.

Pour chiffrer puis encoder :
Procedure Fonc_Crypte(sDatas chaîne)
bufDatas est un Buffer sur 128 = sDatas
sCle est un Buffer = HashChaîne(HA_HMAC_MD5_128, "maClé")
bufHash est un Buffer = CrypteStandard(bufDatas, sCle)
bufHash = Encode(bufHash, encodeBASE64URL)
RENVOYER bufHash

Pour décoder puis déchiffer :
Procedure Fonc_Decrypte(sCrypte chaîne)
bufHash est un Buffer = sCrypte
sCle est un Buffer = HashChaîne(HA_HMAC_MD5_128, "maClé")
bufHash = Decode(bufHash, encodeBASE64URL)
bufHash = DécrypteStandard(bufHash, sCle)
sDecrypte est une chaîne = SansCaractèreDroite(bufHash, "0")
RENVOYER sDecrypte

A noter que je passe par une API pour communiquer avec ma BDD, donc je suppose que c'est lors du passage des chaînes chiffrées en paramètres des requêtes que le souci d'encodage devait se produire.

Cordialement,

--
Cecile D.
Posté le 25 mai 2021 - 11:45
Bonjour,

Merci Cécile pour l'astuce du Encode.
J'ai aussi demandé des chaines ANSI dans les paramètres des fonctions.

J'ai énormément galéré pour envoyer une chaine cryptée d'un mobile ios vers un webservice du PCSCLOUD.
Le format de chaine est toujours rejeté si je n'utilise pas la fonction Encode Decode comme conseillée par Cécile.

Encore merci.
Posté le 11 mars 2024 - 11:20
Merci pour cette solution qui répond parfaitement à mon problème