Bonjour à tous,
Je me suis mis en tête de passer un de mes programmes, écrit en Python, en application web (parce que c'est à la mode). Ce dernier utilise un poil AES, je dois donc réussir à déchiffrer avec Javascript mes données écrites avec Python. Évidemment, si j’écris sur les forums, c’est que je n’y arrive pas. À la place, je tombe sur un résultat plutôt « rigolo », voyez par vous même :
key = "Fr+qgqTMOfNiB1N7Zkl6IBHwzW3b0FnnoE2jiRzpLv4=" (base64)
key = "16bfaa82a4cc39f36207537b66497a2011f0cd6ddbd059e7a04da3891ce92efe" (hex)
iv = "ACcbhcUMudd4j5M3mPlqYg==" (base64)
iv = "00271b85c50cb9d7788f933798f96a62" (hex)
plain = "test"
Python:
import base64
import Crypto.Cipher.AES
key = "Fr+qgqTMOfNiB1N7Zkl6IBHwzW3b0FnnoE2jiRzpLv4="
iv = "ACcbhcUMudd4j5M3mPlqYg=="
plain = "test"
print base64.b64encode(Crypto.Cipher.AES.new(base64.b64decode(key), Crypto.Cipher.AES.MODE_CFB, base64.b64decode(iv)).encrypt(plain))
# result: 9G1IBw==
OpenSSL:
openssl enc -aes-256-cfb -e -a -K 16bfaa82a4cc39f36207537b66497a2011f0cd6ddbd059e7a04da3891ce92efe -iv 00271b85c50cb9d7788f933798f96a62 <<< test
# result: 9CIFd3c=
JavaScript (http://code.google.com/p/crypto-js/):
var key = CryptoJS.enc.Base64.parse("Fr+qgqTMOfNiB1N7Zkl6IBHwzW3b0FnnoE2jiRzpLv4=")
var iv = CryptoJS.enc.Base64.parse("ACcbhcUMudd4j5M3mPlqYg==")
document.getElementsByTagName("textarea")[0].value =
CryptoJS.enc.Base64.stringify(CryptoJS.AES.encrypt("test", key, {iv: iv, mode: CryptoJS.mode.CFB}).ciphertext);
# result: 9CIFd3FW/bSnzs0Sn3ZPBA==
Et oui : même clé, même IV, même algorithme, même mode (CFB, parce que la doc me dit que c’est le bien et que je suis un ignare dans le domaine, donc je suis bêtement la doc), et trois résultats différents ! Et bien évidemment, aucune implémentation n’arrive à déchiffrer le résultat des autres…
Quelqu’un s’y connaissant un peu plus que moi saurait où je me suis loupé ?
# CBC
Posté par superna (site web personnel) . Évalué à 2.
Si j'étais toi j'utiliserais CBC, qui est plus simple. Je doute que CFB ne t'apporte grand chose….
Il y a peut être une différence d'encodage du plaintext…
[^] # Re: CBC
Posté par Moonz . Évalué à 2. Dernière modification le 28 octobre 2013 à 17:18.
Le problème de CBC c’est que je dois faire le padding à la main et que non content d’être fainéant je crains de ne pas avoir tout compris au scheme de padding de PKCS#7…
Mais tu as raison dans le fond, avec CBC ça marche. Ce qui rend les choses d’autant plus étranges d’ailleurs…
[^] # Re: CBC
Posté par Moonz . Évalué à 4. Dernière modification le 28 octobre 2013 à 17:31.
Bon, finalement le fait que CBC marche et pas CFB m’a mis sur la bonne direction : http://lists.dlitz.net/pipermail/pycrypto/2012q2/000594.html
Si je met segment_size=64 dans Python ça marche, mais ça m’oblige aussi à faire du padding en CFB aussi du coup.
There ain't no such thing as a free lunch :(
# \n
Posté par Krunch (site web personnel) . Évalué à 2.
C'est pas encore ça mais bon.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# j'ai pas vraiment de solution
Posté par maboiteaspam . Évalué à 1.
Hello,
J'ai déjà rencontré ce problème sur des sommes SHA (hum hum), une appli java porté vers php (et oui.), la somme sha java était totalement foireuse.
Ce que nous avions fais à l'époque, merci le libre, était d'avoir un petit conteneur java que l'on pouvait appeler depuis php.
Celui ci nous permettait de reproduire les hash erronés fournit par la plate forme java et de les traiter ensuite dans la partie php.
Donc, je me demande de quels de backend tu disposes, et si cette expérience ne pourrait pas être reproduite.
J'ai bien conscience des problèmes de perf / maintenance. Mais bon, ça c'est à chacun de juger en fonction de son contexte.
a+
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.