8
votes

Le cryptage AES dans Oracle et MySQL donnent des résultats différents

J'ai besoin de comparer les données entre une base de données Oracle et une base de données MySQL.

en oracle, les données sont d'abord cryptées avec l'algorithme AES-128 CODE>, puis hachée. Ce qui signifie qu'il n'est pas possible de récupérer les données et de le déchiffrer. P>

Les mêmes données sont disponibles dans MySQL et en texte brut. Donc, pour comparer les données, j'ai essayé de crypter, puis en hachage les données MySQL tout en suivant les mêmes étapes effectuées dans Oracle. P>

Après beaucoup d'essais, j'ai enfin découvert que le aes_encrypt code> Dans MySQL renvoie différents résultats que ceux de Oracle. P>

-- MySQL
-- While doing the same with MySQL, I have tried the following:
SELECT hex(aes_encrypt('test-data', MD5('test_key'));


5 commentaires

À première vue, je soupçonne que le problème d'être ici: 'test_key', 'al32utf8' Methinks MySQL a une indigne de caractères différente sur vos données et donc des données différentes avant que le cryptage soit appliqué.


Je soupçonne que le cryptage devrait être identique, alors je voudrais que les clés soient identiques. I.e. MD5 renvoie-t-il une chaîne hexagonale ou des octets bruts. Si hex, qu'en est-il de l'affaire? Malheureusement, je n'ai pas accès à Oracle avec DBMS_Crypto installé.


@Sodved Oui Le hachage MD5 donne le même résultat dans les deux bases de données 8C32D1183251DF9828F929B935AE0419 . Et comme c'est le cas @johan, il ne devrait pas être un problème de codage car le hachage de MD5 est le même


Vous risquez peut-être mieux de spécifier explicitement le IV des deux côtés. Vous devez également spécifier explicitement le rembourrage à utiliser des deux côtés: PKCS7 est habituel pour les AES.


@rossum Le rembourrage par défaut dans MySQL est PKCS7, MMM ... Oh .. à Oracle Il utilise PKCS5, je ne peux pas croire que je n'ai pas remarqué cela. Merci. (BTW Oracle n'a pas l'option PAD_PKCS7, pas en 11g au moins)


3 Réponses :


0
votes

pourrait être CBC VS BCE. Commentaire au bas de cette page: http: //dev.mysql .Com / Doc / Refman / 5.5 / FR / Encryption-Fonctions.html dit la fonction MySQL utilise la BCE


2 commentaires

J'ai vu ce commentaire et j'ai essayé de la BCE à Oracle pour voir si cela donne un résultat différent, mais ce n'était pas le cas. Ce qui est effectivement le résultat attendu car la BCE et la CBC sont fondamentalement identiques si l'IV n'a pas été envoyé à la fonction de chiffrement. (Sa valeur par défaut est null )


@Dan: Ils ne sont identiques que si un seul bloc est crypté. Avec un rembourrage, ce qui a commencé comme exactement un bloc unique (16 octets) peut s'étendre à deux blocs en raison du rembourrage.



8
votes

La fonction MD5 em> de MySQL renvoie une chaîne de 32 caractères hexadécimaux. Il est marqué comme une chaîne binaire, mais ce n'est pas les données binaires de 16 octets que l'on s'attendait.

Pour le réparer, cette chaîne doit être reconvertie aux données binaires: P>

8FCA326C25C8908446D28884394F2E22


0 commentaires

1
votes

Voulez-vous simplement donner la solution complète pour les mannequins basés sur la réponse très didactique de @ Codo.

Edit: Pour être exact en général, j'ai trouvé ceci: - "PKCS # 5 Le rembourrage est un sous-ensemble de PKCS # 7 Rembourrage pour une tailles de bloc de 8 octets". Si strictement pkcs5 ne peut pas être appliqué à AES; ils signifient pkcs7 mais utilisent leur Noms de manière interchangeable. P>

À propos de PKCS5 et PKCS7 P>

/ * MySQL utilise une clé de pliage non standard. * Afin d'obtenir le même résultat dans MySQL et Oracle (ou .NET ou Java), Utilisez uniquement des clés de 16 octets longs (32 symboles hexadécimaux) = 128 bits Le cryptage AES, le mySQL AES_ENCRYPT par défaut. * * Cela signifie que MySQL admet une longueur de clé entre 16 et 32 ​​octets Pour 128 bits, le cryptage AES, mais il n'est pas autorisé par la norme AES d'utiliser une clé non-16 octets, alors ne l'utilisez pas comme vous ne pourrez pas Pour utiliser le standard AES Decrypt dans une autre plate-forme pour les clés avec plus que 16 octets et seraient obligés de programmer le pliage MySQL de La clé de cette autre plate-forme, avec le XOR, etc. (C'est déjà là-bas mais pourquoi faire des choses étranges non standard peut changer lorsque MySQL décider, etc.). De plus, je pense qu'ils disent que l'algorithme choisi par mysql pour ceux-ci Les cas sont vraiment mauvais choix sur un niveau de sécurité ... * / p>

- ### oracle: p>

- d'abord la clé est hachée avec MD5 pour en faire une touche 128 bits (16 octets, 32 symboles hex): p> xxx pré>

- mysql utilise al32utf8, au moins par défaut p>

- Configurez les paramètres de cryptage: P>

SELECT hex(aes_encrypt('test-data', unhex(MD5('test_key')));


0 commentaires