Hello,
Je souhaite vérifier que le chiffrement python peut être interopérable avec d'autre outils :
#!/usr/bin/python
from Crypto.Cipher import AES
cipher = AES.new("totototototototo")
print cipher.encrypt("tatatototatatoto");
mais quand je tente de déchiffrer la sortie standard avec openssl :
openssl enc -d -aes-128-cbc -k "totototototototo"
Il me retourne un laconique "bad magic number"
Comment faire pour que openssl comprennent python. ?
# 3bune
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Sur la tribune tu postais une ligne plus complète, ton python faisait un import de aes base64. Tu es sûr que, plutôt qu'un pb avec PyCrypto, tu n'es pas simplement en train de demander de déchiffrer en 128 un truc qui a été chiffré en 256 par défaut ??
J'ai pas cherché à savoir quel était celui choisi par défaut, c'est juste que chez moi c'est 256.
[^] # Re: 3bune
Posté par Hardy Damien . Évalué à 1.
Oui j'ai simplifié pour bien isoler le problème.
J'ai le même résultat avec tout les "aes" possible de openssl :
(test.py étant égal au contenu de mon post)
# openssl
Posté par BFG . Évalué à 7. Dernière modification le 07 février 2012 à 22:53.
Essayons de chiffrer avec openssl :
La sortie fait 48 octets, alors que votre programme produit 16 octets (qui est la longueur d'un bloc chiffré). Donc openssl s'attend à plus d'informations dans ce mode (en fait, il s'attend à obtenir un fichier produit par "openssl enc -e", qui donnera le bon format).
On peut cependant l'utiliser dans un mode plus brut :
On obtient donc le bon résultat.
"-k" va tenter de dériver une clef à partir de son argument mot de passe, alors que vous passiez une clef au chiffrement en Python. Pour passer la clef, il faut utiliser "-K", et passer un "-iv" puisque vous utilisez CBC.
Cependant, on ne saurait trop vous recommander de ne pas utiliser les primitives de chiffrement, comme AES-CBC. AES-CBC ne réalise qu'un chiffrement, et ne permet pas à lui seul une vérification d'intégrité. Il faut par exemple lui adjoindre un chiffrement haché (HMAC). Et cela ne suffit pas pour les transmissions réseaux. Attaques par rejeu etc. sont au programme.
Il est facile avec le chiffrement de se croire en sécurité, alors qu'il faut faire attention à de nombreuses choses, même en ne parlant que des aspects techniques. Utilisez des programmes (GnuPG (il sait réaliser des chiffrements symétriques)) ou des protocoles (SSL/TLS (TLS-PSK pour le chiffrement symétrique)) existants, plutôt que réinventer votre chiffrement. Sauf bien sûr, si c'est dans un but pédagogique.
Un article intéressant à ce sujet (bien qu'un peu trop distrayant, et qu'un passage ne soit pas clair du tout, nécessitant de lire Wikipedia à côté) : If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong.
[^] # Re: openssl
Posté par Hardy Damien . Évalué à 1.
Super,
Merci pour ces explication.
Le code est inspiré de https://github.com/globocom/thumbor/
et https://github.com/globocom/thumbor/blob/master/thumbor/crypto.py en particulier
Le but ici est de transformer :
http://serveurthumbor/unsafe/fit-in/560x420/filters:fill(blue)/url/to/image.jpg
en :
http://serveurthumbor/lfcBvO4PIwuukgT6cY...QbAmH0Nl20U=/url/to/image.jpg
Pour que seul une webapp autorisée (par la connaissance de la clé) puisse exploiter le service de redimensionnement d'image thumbor.
Je voulais m'assurer que le chiffrement puisse être généré par autre chose qu'une application python.
[^] # Re: openssl
Posté par BFG . Évalué à 3.
Comme vous le dites, ici le but est d'authentifier, et non réellement de masquer les paramètres. L'article que j'ai mentionné est donc d'autant plus vrai : n'utilisez surtout pas uniquement le chiffrement des paramètres !
Il suffirait à un attaquant de relever une URL qui fonctionne, et de modifier des bits, il pourrait alors obtenir une autre URL qui sera bien évaluée par le serveur, mais qui contiendra des paramètres différents une fois déchiffrée. Pourquoi ? Parce que le chiffrement n'est pas une authentification.
Je vous conseille de hacher les paramètres et chiffrer le hachage (avec HMAC par exemple, qui est très commun (et disponible en Python)), le hachage chiffré agira comme une signature, une authentification.
Les paramètres peuvent être chiffrés si vous souhaitez les masquer, mais ce n'est pas nécessaire si tout ce que vous souhaitez est une authentification.
Vous pouvez aussi ajouter une date d'expiration aux paramètres (à signer), et ainsi empêcher quelqu'un de "rejouer" des URL qui étaient bien valides.
[^] # Re: openssl
Posté par Hardy Damien . Évalué à 1. Dernière modification le 09 février 2012 à 17:39.
"n'utilisez surtout pas uniquement le chiffrement des paramètres !"
Oui c'est pour cela que dans le chiffrement selon l’algorithme de thumbor il y a aussi le md5 de l'url de l'image (ici url/to/image.jpg) ajouté après les paramètre. du coup chaque url devient unique paramètre + image comprise et difficile à copier (je n'ose pas dire impossible)
[^] # Re: openssl
Posté par BFG . Évalué à 2.
Je n'avais pas vu, effectivement c'est beaucoup mieux.
Mieux, mais pas dans les règles de l'art. C'est à se demander (je plaisante bien sûr) s'ils ne tenaient pas à faire les fortes têtes, déjà rien qu'en utilisant MD5, un algorithme affaibli. Ensuite, un seul hachage suffit souvent, mais si HMAC hache 2 fois (une fois avant le XOR, et une après), c'est qu'il y a une raison.
Vous pouvez dormir sur vos deux oreilles, j'arrête ici mes lamentations.
[^] # Re: openssl
Posté par briaeros007 . Évalué à 1.
j'ai essayé de lire ton article, je l'ai trouvé illisible. la forme n'aide pas du tout pour comprendre.
Un pseudo dialogue qui n'aide en rien, des changements de plans qui rajoutent juste à la confusion, avec des noms à ralonges et du n'importe quoi esque au beau milieu qui ne semble être là juste à perdre encore un peu plus le lecteur.
Le fond est fouilli, on change allégrement de chose regardée, on passe très vite sur certains passages, on explique vraiment pas grand chose, et le peu qu'on explique, au beau milieu, on a changé trois fois de sujet.
Et je ne parle même pas du coté "nous on est trop fort, tout le monde ils sont quand même nul" qui transparait à travers l'article.
[^] # Re: openssl
Posté par BFG . Évalué à 2.
J'avais prévenu qu'il était un peu trop distrayant, mais on peut en faire abstraction si l'on veut. Si par contre, on a décidé qu'il serait "illisible", "fouillis", alors je ne vois rien à répondre.
Les passages techniques sur les modifications de bits nécessitent de toute façon un crayon et un papier, cela vous dérange tant que ça ? Si vous ne les comprenez pas ou ne voulez pas essayer, alors acceptez la conclusion que ce n'est pas pour vous et qu'il faut vous en tenir aux protocoles existants.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.