[pycrypto] the sad state of pycrypto
Dwayne C. Litzenberger
dlitz at dlitz.net
Sun Nov 9 11:50:41 CST 2008
On Sun, Nov 09, 2008 at 09:58:00AM -0700, zooko wrote:
>On Nov 9, 2008, at 8:54 AM, Paul Hoffman wrote:
>> The idea of dropping support for "weak" algorithms is silly. No
>> developer looks through the list of algorithms in a library and say
>> "I'll pick, um, er, that one" without knowing what it is.
>I happen to know a somewhat famous developer who once looked through
>the Crypto++ API and chose DES-XEX without (I think) realizing that
>it was DES-X and not Triple-DES.
>But yeah, modelling the developers who use your library -- guessing
>how clueful and careful they will be -- is a black art and is
>probably doomed to failure.
But can we make bad choices more difficult to make?
One think I am considering is to allow the developer to select a
pre-defined "policy" (set of constraints), and then raise an exception or a
warning whenever the program does something that would violate this policy.
The policies themselves would be frozen (so legacy code could still use
legacy algorithms), but we could create new policies as necessary,
encourage developers to use the latest policies for new code, and provide
users with tools (environment variables?) to further constrain the policy
selections in order to find places where obsolete policies might be in use.
So, hypothetically, you would have something like this:
>>> from Crypto import CryptoAPI
>>> from Crypto.Policy.p2008v1 import ConservativePolicy
>>> api = CryptoAPI(policy=ConservativePolicy)
>>> h = api.Hash.MD5.new()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
PolicyError: MD5 hash not allowed by policy <2008.1.ConservativePolicy>
This would probably involve concentrating all object creation into a single
"factory", so I'm not quite sure how to shoehorn the current PyCrypto API
This would also make unit testing easier, since we could substitute dummy
functions for real ones. Also, things like Util.number.isPrime could more
easily be made non-deterministic (giving them access to the user's selected
RNG) without having to change the external API.
Dwayne C. Litzenberger <dlitz at dlitz.net>
Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9 179F 1C11 B877 E780 4B45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/359ab7bf/attachment.pgp
More information about the pycrypto