PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → CrypteStandard() AES vs AES_DECRYPT MySQL
CrypteStandard() AES vs AES_DECRYPT MySQL
Débuté par nenex73, 05 aoû. 2015 00:39 - 15 réponses
Membre enregistré
10 messages
Posté le 05 août 2015 - 00:39
Bonjour à tous,

Je cherche un moyen de chiffrer une chaine en AES sous windev, l'envoyer à MySQL et enfin déchiffrer avec AES_DECRYPT.
Et force et de constater que je n'arrive à rien :-(

Il est indiqué dans la doc WD (http://doc.pcsoft.fr/?1000021293&lang=fr-FR&productversion=xxF200066p) que :
Si le message doit être décrypté :
- par la fonction DécrypteStandard, il suffit de passer l’intégralité du buffer à la fonction.
- par un outil tiers, il est nécessaire de découper le buffer pour séparer le vecteur d’initialisation des données cryptées (voir exemple).
Remarque : Si le mode d’opération spécifié est crypteECB , aucun vecteur d’initialisation n’est utilisé et dans ce cas la fonction retourne directement les données cryptées.

Mais :
- L'utilisation de crypteECB ne permet pas le déchiffrement avec AES_DECRYPT même si " le mode d’opération spécifié est crypteECB , aucun vecteur d’initialisation n’est utilisé et dans ce cas la fonction retourne directement les données cryptées."
- L'exemple "voir exemple" dont il est fait mention n'existe pas (même en cliquant sur "Voir exemples supplémentaires")
Donc impossible de "découper le buffer pour séparer le vecteur d'initialisation des données cryptées"
Dois-je supprimer les 128 premiers bits (16 octets soit 8 caractères) du buffer ?

Toute aide sera la bienvenue.
Membre enregistré
2 messages
Posté le 11 octobre 2018 - 11:54
Salut,

Ben j'ai le même problème actuellement... y a t'il des solutions (depuis trois) pour décrypter un encryptage fait par MYSQL avec AES _CRYPT ?

dans d'l'attente d'une bonne âme...
merci d'avance
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 11 octobre 2018 - 12:29
Bonjour,

Ne serait-ce pas un problème d'encodage de caractères ?

--
Cordialement,

Philippe SAINT-BERTIN
Message modifié, 11 octobre 2018 - 12:29
Posté le 11 octobre 2018 - 17:00
C'est la question à 1 million de $.
3 ans sans personne pour y répondre...
Et j'ai la réponse :)

En windev :
bufEnClair=ChaîneVersUTF8("Ma chaîne à chiffrer")
bufChiffré=CrypteStandard(bufEnClair,"ma_clé_de_cryptage",crypteAES128,crypteECB,cryptePaddingPKCS)
strRéponse=Remplace(Crypte(bufChiffré,"",crypteAucun,encodeBASE64),RC,"")

En Maria :
SELECT AES_DECRYPT(FROM_BASE64("Ce qu'il y avait dans strRéponse"),'ma_clé_de_cryptage')

Bon courage.
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 12 octobre 2018 - 07:33
D'un autre côté, il est écrit dans l'aide de passer les chaînes en UTF8 pour la compatibilité entre toutes les plateformes.

--
Cordialement,

Philippe SAINT-BERTIN
Posté le 12 octobre 2018 - 10:42
Philippe SB a écrit :
> D'un autre côté, il est écrit dans l'aide de passer les chaînes en UTF8 pour la compatibilité entre toutes les plateformes.

Il ne vous aura sans doute pas échappé qu'il y a plus de "problèmes" qu'un simple encodage ?
De plus l'encodage n'a rien à voir.
Quand PCSoft parle de plateformes, il parle de WD, WM, WB.
Là il n'est question que de WD.
Moi j'encode en utf8 à la source car je sais que je vais décoder sur une plateforme linux configuré utf8.
Mais si j'avais été sous windows, j'aurais très bien pu rester en ansi.
Vous étiez libre de répondre à la question pendant 3 ans. Pourquoi ne pas l'avoir fait ?
Je pense qu'Alain préférera ma réponse avec un bout de code fonctionnel qu'un conseil plus ou moins boiteux que vous lui prodiguez !
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 12 octobre 2018 - 12:05
@alexis rochereuil: je suis désolé d'avoir froissé sa majesté et je m'incline et te remercie de m'avoir remis à ma place. Je vais moi même te faire quelques petites remarques:

Quand PCSoft parle de plateformes, il parle de WD, WM, WB.

Extrait de l'aide:
les fonctions CrypteStandard et DécrypteStandard utilisent des algorithmes de cryptage standard qui permettent d’échanger des messages cryptés entre des plateformes d’exécution différentes (Windows, Linux, Android, Java, iOS, PHP, etc.) et/ou avec des outils tiers 

Il faut donc apprendre à lire avant de critiquer.

D'autre part, tout le monde n'utilise pas MySQL. Pour ma part je trouve ce SGBD, lent, non sécurisé et inefficace. Cela n'est que mon avis personnel et je ne souhaite en aucun cas, ici, lancer une guerre puéril entre les SGBD. Ma réponse n'engage que moi.

Ne connaissant ni la plateforme, ni le SGBD j'ai tout simplement lancé une piste de recherche.

Ensuite, je suis ravi pour lui que tu es la réponse à sa question. Cependant, tu avais toi aussi 3 ans pour y répondre et tu ne l'as pas fait.

Pour terminer, nous somme ici sur un forum et il serait intéressant de respecter les autres contributeurs et ne pas les dénigrer. Cependant, il est vrai que cela demande un peu de savoir vivre. Je pense avoir aidé pas mal de monde sur le forum et ce n'est pas pour autant que ça fait de moi un être supérieur aux autres. Tout le monde peut donner son avis dans le respect de chacun. Encore une fois cela demande un peu de savoir vivre

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
2 messages
Posté le 12 octobre 2018 - 15:26
Bonjour et merci à tout le monde...

Bon vous m'avez bien aidé... Il y a des choses bizarres qui m'ont ralenti mais j'ai réussi à m'en sortir.
Le problème majeur que j'avais c'est que je générais une clé sur 128 et qu'il m'envoyais balader en me disant que ma clé était trop longue... 208 bits
pour résoudre le problème j'ai mis le buffer sur 16 et il m'a tronqué le rab... et ça marche.

Par contre pourquoi après avoir fait le cryptestandard tu fais un encodage en base64 ?

Je l'ai enlevé et ça fonctionne.... Tu dois avoir une bonne raison ?

super merci

Alain FALGAYRAC
Posté le 12 octobre 2018 - 16:37
@Philippe SB :
Ne vous connaissant pas, je préfère le vouvoiement plus de rigueur me semble-t-il.

En me relisant, j'ai peut-être été un peu cassant, désolé.
Mais il est vrai que j'ai trouvé votre intervention pas très constructive à la suite d'un bout de code lui parfaitement fonctionnel.
S'il y avait eu erreur d'encodage, Alain aurait eu quelques caractères cabalistiques bien connus.
Et sa question aurait été tout autre.
Donc j'ai trouvé déplacé votre insistance sur votre 2ème message "ah bah je vous l'avais bien dit que c'était un pb d'encodage".
Alors que la vraie "difficulté" c'était de trouver les bons paramètres à la fonction CrypteStandard(...,crypteAES128,crypteECB,cryptePaddingPKCS)
A noter que nenex73 c'est moi.
Mais comme PERSONNE n'avait manifesté d'intérêt pour la question, je ne me suis pas répondu pour indiquer la solution.
Même 3 ans après...

"les fonctions CrypteStandard et DécrypteStandard utilisent des algorithmes de cryptage standard qui permettent d’échanger des messages cryptés entre des plateformes d’exécution différentes (Windows, Linux, Android, Java, iOS, PHP, etc.) et/ou avec des outils tiers.
Il faut donc apprendre à lire avant de critiquer."
Vous remarquerez qu'il n'est nul part fait mention d'encodage en utf8 dans cette page d'aide... (https://doc.pcsoft.fr/?1000021293&verdisp=160).
Or c'est sur cette utilisation d'utf8 (d'encodage donc) que nous ne sommes pas d'accord.

"D'autre part, tout le monde n'utilise pas MySQL. Pour ma part je trouve ce SGBD, lent, non sécurisé et inefficace. Cela n'est que mon avis personnel et je ne souhaite en aucun cas, ici, lancer une guerre puéril entre les SGBD. Ma réponse n'engage que moi."
Je pense que le meilleur moyen de ne pas déclencher de guerre et d'éviter ce genre d'allégations "lent, non sécurisé et inefficace".
Surtout lorsque vous dîtes quelques lignes plus bas "Ne connaissant ni la plateforme, ni le SGBD".
Quand on ne connait pas, on ne dénigre pas.

Après, loin de moi l'idée de me prendre pour une quelconque éminence. Au contraire j'ai répondu à Alain avec rapidité, précision et plaisir pour qu'il puisse se sortir rapidement de l'embarras temporaire dans lequel il était.

@ Alain :
Avec plaisir.
Encodage base64 pour n'avoir que des caractères ASCII et avoir une portabilité maximale (linux, windows, mac).
C'est souvent l'encodage choisit par les logiciels de messagerie, une valeur sûre donc.
Certes ça augmente d'une trentaine de % la taille de la chaîne mais c'est vraiment efficace.
A toi de voir si cela te convient ou pas.
Bonne continuation.
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 12 octobre 2018 - 18:28
@alexis rochereuil
Vous remarquerez qu'il n'est nul part fait mention d'encodage en utf8 dans cette page d'aide... (https://doc.pcsoft.fr/?1000021293&verdisp=160).
Or c'est sur cette utilisation d'utf8 (d'encodage donc) que nous ne sommes pas d'accord.


Je vous engage donc à relire l'aide sur ce même lien que vous citez et plus précisément la partie "Buffer".

Pour la partie sécurité, voici une capture d'écran de l'ODBC MySQL dans la base de registre




Le mot de passe en clair, ça démontre la sécurité extrême de MySQL. C'est pour ça que je dis que c'est non sécurisé. Qu'un expert en sécurité me dise le contraire...

--
Cordialement,

Philippe SAINT-BERTIN
Message modifié, 12 octobre 2018 - 18:29
Posté le 15 octobre 2018 - 18:05
Pour l'encodage :
Je cite l'aide "Il est conseillé d'utiliser des chaînes au format UTF 8".
Donc il s'agit d'un CONSEIL et qui plus est s'applique au paramètre CLÉ et non au paramètre message.
On est assez loin du concept de base qui était "il est écrit dans l'aide de passer les chaînes en UTF8"

Pour Mysql :
Il n'y a pas que ODBC pour accéder à MySQL depuis Windev.
Il y a notamment l'accès natif qui vous fournira de meilleures performances et une sécurité tout à fait convenable.
Surtout si vous mettez en oeuvre du chiffrement et de l'authentification mutuelle (http://www.chicoree.fr/w/Connexion_s%C3%A9curis%C3%A9e_%C3%A0_MySQL…).
Vous êtes libre de choisir une méthode lente et non secure pour vous connecter à mysql mais n'en concluez pas hâtivement que mysql n'est pas sécurisé.
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 16 octobre 2018 - 09:01
Pour l'encodage :
Je cite l'aide "Il est conseillé d'utiliser des chaînes au format UTF 8".
Donc il s'agit d'un CONSEIL et qui plus est s'applique au paramètre CLÉ et non au paramètre message.
On est assez loin du concept de base qui était "il est écrit dans l'aide de passer les chaînes en UTF8"


Je vous engage vivement à tenter de crypter une chaine en ANSI sous WinDev et essayer de la décrypter sous php, Android ou iOS. Je l'ai fait et m'y suis cassé les dents, comme bon nombre de développeur ici, entre ces différentes plateformes. Le passage en utf8 sur le message à crypter et la clé est indispensable.

PHP encode les pages en utf8 (sur Windows ou linux), Android et iOS quant à eux encodent en unicode mais pas sur le même nombre de bits. Vous comprendrez donc aisément qu'il faut un encodage commun à toutes ces plateformes. Le plus rencontré étant utf8, on l'utilise donc en général. Rien ne nous empêcherait d'utiliser utf16 ou 32, sauf que WinDev ne supporte qu'utf8. Voilà l'importance de passer les chaînes en utf8. Il est d'ailleurs bien spécifié dans l'aide:
il est nécessaire d'utiliser le même format sur toutes les plateformes


Maintenant si vous préférez rester en ANSI pour vous limiter dans le nombre de caractères et passer toutes les chaines dans Android et iOS en ANSI, libre à vous.

--
Cordialement,

Philippe SAINT-BERTIN
Posté le 16 octobre 2018 - 09:15
"il est nécessaire d'utiliser le même format sur toutes les plateformes"
Ah oui ça c'est indubitable mais personne ne dit que le format en question doit être de l'UTF8 !
Posté le 16 octobre 2018 - 09:29
Merci Alexis pour le code et le lien … très instructifs !
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 16 octobre 2018 - 10:11
"il est nécessaire d'utiliser le même format sur toutes les plateformes"
Ah oui ça c'est indubitable mais personne ne dit que le format en question doit être de l'UTF8 !


C'est exactement ce que j'ai écrit, encore une fois il faut apprendre à lire et arrêter de sortir une phrase d'un contexte.

Le plus rencontré étant utf8, on l'utilise donc en général. Rien ne nous empêcherait d'utiliser utf16 ou 32, sauf que WinDev ne supporte qu'utf8

...passer toutes les chaines dans Android et iOS en ANSI, libre à vous.


--
Cordialement,

Philippe SAINT-BERTIN
Message modifié, 16 octobre 2018 - 10:12
Posté le 16 octobre 2018 - 11:07
Cyril a écrit :
> Merci Alexis pour le code et le lien … très instructifs !

Avec plaisir.
Ca me semble important de bien sécuriser les accès tant l'exposition d'un serveur SQL est une opération critique.