[pycrypto] On the future of new ciphers/hashes in PyCrypto

[Dwayne C. Litzenberger]

Can block cipher chaining modes be implemented in Python without making 
ridiculous performance sacrifices?  I'm not a Python performance expert, 
but I thought the Python function call overhead was too high.

On Thu, Oct 14, 2010 at 11:10:59PM +0200, Legrandin wrote:
>I think it is worth making a distinction between primitives and protocols.
>
>The few ciphers/hashes that currently exist in pycrypto suffice for
>most needs one may have, and
>I agree that adding more won't help in 99% of the applications (even
>though it may look good
>on a fact sheet) whereas a low-level cipher zoo is hard to maintain.
>
>Having said that, one of beauties of pycrypto is the fact that is
>self-contained and does not require
>to be combined with further packages. A pluggable system - although
>elegant - would become
>less practical and possibly not very considered as a feature. If one
>day one could prove that pycrypto is
>indeed missing a primitive used by some real, widespread systems
>(maybe ECC?) that cannot be sanely
>replaced by AES/TDES/SHA, I would even urge to still have a C
>implementation included from some
>good patent-free library (e.g. tomcrypt) and shipped. So much time saved...
>
>Protocols are another beast though: key derivation/management/exchange
>schemes, wrappers,
>message authentication codes, etc etc are in most cases independent of
>the underlying cipher/hash
>primitive and can be more cleanly and quickly implemented/tested in a
>high-level language like Python
>with little performance penalty. PKCS#1 and PBKDF2 are good examples.
>Even chaining modes
>for block ciphers look better in python (to me at least).I would
>really prefer to have these high-level
>algorithms available in the library and not through some obscure
>openssl-like library coded in C...
>
>My 2 cents... :-)
>
>> Going through the bug tracker and the mailing list, a lot of the requests
>> are to add new algorithms (Camellia, SHA512, TEA, PKCS#1/OAEP, PBKDF2), or
>> to make changes to the existing implementations (timing attack
>> countermeasures for the AES module, better prime generation for RSA).
>
>> They're all good ideas, but I don't have the time or the expertise needed
>> to review C implementations of low-level crypto primitives, and frankly, I
>> have better things to do.
>
>> Python does not need its own custom AES implementation.  Neither do Java,
>> Ruby, Perl, JavaScript, PHP, Go, C++, D, Clojure, Haskell.  It's a waste of
>> volunteer time, it's bad engineering, and it means that the FOSS community
>> ends up repeating the same mistakes over and over, year after year, every
>> time a new language comes out.
>
>> I'm putting a stop to it.  I'm declaring a permanent feature freeze on the
>> C implementations of <Crypto.Cipher.*> and <Crypto.Hash.*>.  New algortihms
>> will be added only by calling out to existing libraries.  PyCrypto
>> development will be focused on the API.
>
>> I haven't yet figured out exactly how this is going to look.  I'm thinking
>> of some kind of pluggable backends, sort of like how Java or CryptoAPI, but
>> with as little API complexity as possible.  Ideas are welcome.
>
>> - Dwayne
>_______________________________________________
>pycrypto mailing list
>pycrypto at lists.dlitz.net
>http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
  OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7