[pycrypto] the sad state of pycrypto

[Dwayne C. Litzenberger]

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 
into it.

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.

Thoughts?

-- 
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
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/359ab7bf/attachment.pgp