|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
Problème avec DecrypteStandard |
Débuté par Philippe SB, 02 aoû. 2016 13:10 - 22 réponses |
| |
| | | |
|
| |
Membre enregistré 2 571 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 571 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 571 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 144 messages Popularité : +50 (142 votes) |
|
Posté le 01 juin 2020 - 12:06 |
| |
| |
| | | |
|
| | |
| |
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 571 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 571 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 144 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 )
-- 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 )
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 571 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 144 messages Popularité : +50 (142 votes) |
|
Posté le 08 mars 2021 - 13:47 |
| |
| |
| | | |
|
| | |
| |
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
Procedure UID256_Decode_b( LOCAL Encoded_s64 is ANSI string, LOCAL Key_Uk is 256-bit UUID, Decoded_s is ANSI string = "") WHEN EXCEPTION IN Crypt_m is Buffer = Decode (Encoded_s64) Prv_h is Buffer = Key_Uk 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]) Decoded_s = "";RESULT False END Pack_s is ANSI string = Pack_m CRC_Got_s is ANSI string = Pack_s[1 TO 8] Data_Got_s is ANSI string = Pack_s[9 TO Length(Pack_s)] 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 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)
CRC_s is ANSI string = UID_CRC_s64(Clear_s) 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 RESULT "" END CAS ERREUR: RESULT ""
|
| |
| |
| | | |
|
| | |
| |
Membre enregistré 2 571 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 |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|