[pycrypto] Pycrypto, New contributor, TODO & Camellia
Dwayne C. Litzenberger
dlitz at dlitz.net
Sun Nov 15 02:39:47 CST 2009
On Sat, Nov 14, 2009 at 05:39:40PM +0800, rusydi hasan wrote:
>First of all, let me introduce myself. Im rusydi, an undergaduate computer
>science in malaysia.
>I have necessary background in cryptography, specifically block cipher, and
>C programming. Im interested to become a contributor in the next release of
>pycrypto (i read that you need the contributor outside US and Canada and not
>the US/Canada Passport holder), especially in the implementation of some
>block ciphers. But i have few things that i need to ask to you
That's great! One correction: I only ask that contributors be non-US
citizens/residents. Canada is fine; I'm Canadian. :)
> 1. In TODO list i saw that pycrypto is gonna implement Camellia. AFAIK,
> camellia is a patented block cipher by Mitsubishi Electric Corporation and
> Nippon Telegraph and Telephone Corporation (NTT), Japan. I attached the
> intellectual property statement, submitted to NESSIE submission
Yes, but there is also this:
Announcement of Royalty-free Licenses for Essential Patents
of NTT Encryption and Digital Signature Algorithms
See also the list at:
> 2. Is it necessary to implement some Light-Weight Block Cipher in
> pycrypto ? (such as DESL, TEA, KATAN, SEA, etc) because im planning to
> submit some of these light-weight block cipher for the pycrypto.
I've never heard of any of these ciphers except for TEA, and TEA is
vulnerable to a practical related-key attack.
I am reluctant to add any more 64-bit block ciphers, since you can expect
block collisions after only 2**32 blocks (32 GiB of data) in some modes,
and they're tricky to use in CTR mode with long-term keys (again, because
the collision probability is too high).
I am also very reluctant to add any variants of DES, since pretty much
every variant of DES has been weaker than DES itself.
I don't want to maintain additional ciphers in my tree unless they are
mature and offer significant advantages over what PyCrypto already has.
I'm even hesitant to add Camellia---The only reason I'm considering it is
that PyCrypto only has one 128-bit block cipher right now (AES), and
because the proposed candidate, Camellia, made it through the NESSIE
competition. Even then, I don't consider it a priority, and PyCrypto 2.1
will be released without it.
I'm much more interested in making the crypto we already have less
error-prone to use. For example, we need a PKCS#1 v2.1 implementation, a
*complete* DSA implementation, improved RSA key generation, improved
primality testing, more test cases, a Diffie-Hellman implementation, a
reworking of the Crypto.PublicKey API, and a thorough de-linting of the C
That said, some people might find your code to be useful, even if it
doesn't get included in PyCrypto, so feel free to post it to the mailing
> 3. How to submit the source code ? since i could not clone the git
> repository (the port is blocked from my campus network). And i dont have
> adequate background in open-source software development.
Your campus network support people need to stop interfering with the
end-to-end operation of the Internet Protocol, and to actually start doing
their job, which is to support you, rather than shifting that burden onto
You should be able to clone from
As for submitting source code, you should publish your changes somewhere,
such as by doing one of the following things:
- Post your patches to the mailing list using "git send-email".
- Generate a series of patches using "git format-patch" and send them to
the mailing list yourself.
- Create a git repository somewhere and announce it on the mailing list.
Dwayne C. Litzenberger <dlitz at dlitz.net>
Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
Annual key (2009) - C805 1746 397B 0202 2758 2821 58E0 894B 81D2 582E
More information about the pycrypto