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

[Paul Koning]

I tend to think of ciphers and modes as belonging together, while protocols are separate.  The former I'd expect to find in C, the latter in Python.  But you're right, that assumption depends on the guess that Python call overhead is too high to construct modes in Python out of single-block cipher operations done in C.

That said, I don't know if that's the actual issue.  You make a comment about not wanting to add new algorithms, such as Camellia and TEA (ciphers) and PKCS1 (a protocol, essentially) or PKDF2 (no idea what that is).

In all cases, one of the questions to ask is whether adding lots of things is a good idea.  When crypto is involved, more is NOT necessarily a good thing.  Adding ciphers of uncertain strength (like TEA) or limited applicability along with limited evaluation (Camellia, perhaps?) isn't all that helpful.  I'd much rather see a small library that supports known strong ciphers, modes, and protocols only.

	paul

On Oct 22, 2010, at 11:52 AM, Dwayne C. Litzenberger wrote:

> 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
> _______________________________________________
> pycrypto mailing list
> pycrypto at lists.dlitz.net
> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto