Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

Pourquoi Python n'intègre pas un module natif pour faire de la crypto (AES, DES etc.) ?

+6 votes

J'ai beau chercher, je n'arrive pas à connaitre la raison. J'en vois peut être une qui serait "ces modules ont un cycle de mise à jour peut être plus rapide que le reste des modules python" mais bon c'est pas une raison si valable que ça.

Du coup en attendant, il faut utiliser des libs tierces (pyCrypto etc.) dont il faut faire l'hypothèse que les utilisateurs les ont installées...

demandé 22-Jul-2015 par toto (194 points)
edité 22-Jul-2015 par toto

J'imagine que tu as deja demandé sur la liste. Cela te derange tant que ça, utiliser une lib tierce que la doc officielle recommande d'ailleurs d'utiliser?

C'est vrai, je me suis toujours posé la question également.

J'ai déjà utilisé ce que propose en interne le langage Golang pour gérer de la crypto, c'était très plaisant de travailler avec les outils proposés par défaut.

D'autant qu'on a souvent des problèmes avec cette librairie pycrypto, par exemple si vous installez Twisted avec tahoe-lafs par exemple, vous aurez un conflit de versions.

Un autre probleme de pycrypto, c'est le manque de maintenance : la dernière release date de 2013.

Le module cryptography tente entre autres de répondre a ça (cf why a new crypto library for python)

Le github du projet : https://github.com/pyca/cryptography

@jc

Merci pour l'info ! Faut que je regarde cela.

2 Réponses

+7 votes

Si on se réfère à ce ticket, les dev n'ont pas l'air opposé à cette idée. La majorité des commentaires étant des discussions concernant l'API d'un tel module. D'ailleurs l'un des derniers commentaire explique bien que le problème n'est pas qu'il n'y ai pas d'intérêt mais que tout le monde n'est pas d'accord sur l'implémentation. De plus, une personne fait remarquer que cette inclusion pourrait poser des problèmes légaux dans certains pays.

répondu 23-Jul-2015 par Kje (464 points)
+1 vote

J'en vois peut être une qui serait "ces modules ont un cycle de mise
à jour peut être plus rapide que le reste des modules python" mais bon
c'est pas une raison si valable que ça.

C'est une raison très valable car : https://twitter.com/gvanrossum/status/9479647981

Il est très lent modifier un module de la stdlib, car en dehors des correctifs de sécurité, il faut attendre la prochaine release. Ca veut dire que si demain on s'apperçoie qu'un algo n'est plus fiable et qu'il en faut un nouveau, il faudra attendre un an avoir de l'avoir à dispo, minimum, car c'est une nouvelle feature et pas une correction.

C'est un problème inhérent avec la manière dont python est déployé, et est en discussion régulière : faudrait-il mettre des modules "stdlib officiels" séparé de l'installation de base, sur pypi, mais plus souvent à jour ?

Quoiqu'il en soit le débat continue, et c'est vrai que ça serait très pratique. Une solution actuellement utilisée est de créer des bindings pour des outils quasiment toujours installés. Par exemple le module SSL délègue sa crypto à OpenSSL qui est normalement toujours dispo sur Mac, windows ou Linux.

répondu 2-Aou-2015 par Sam (4,984 points)
...