Add support for Camellia block cipher

[Yoshisato YANAGISAWA]

I would like to post a patch to add support for Camellia block cipher to pycrypto. Camellia is one of the selected block cipher by New European Schemes for Signature, Integrity, and Encryption (NESSIE) and specified in several RFCs. It is also included in some open source softwares, such as FreeBSD, Linux, OpenSSL, Firefox 3, GnuPG and so on. You can get detailed
information for Camellia from:
http://info.isl.ntt.co.jp/crypt/eng/camellia/index.html

Will you review and test it?
I hope my patch will be imported into pycrypto.
Note that I have also posted the same bug report to:
http://sourceforge.net/tracker/index.php?func=detail&aid=2054677&group_id=20937&atid=320937
Since I thought the bug tracking system above has not been working, I will also post the same patch to this bug tracking system.

Thank you in advance.

[Darsey Litzenberger (dlitz)]

Thank you for your patch!

The goals for the next release are:
- to fix bugs
- to deal with potential copyright issues, and
- to fix long-standing problems with how people generate random numbers for use with PyCrypto.

The resulting set of changes is already fairly large, and I don't want to make it larger by adding new ciphers, so Camellia will probably not be included in the next release. I will consider it for future releases, however.

Looking at your patch, I noticed that you have included copyright licensing statements in camellia.c and camellia.h, but the author's name and copyright licensing for the PyCrypto-specific parts of the patch are missing. The ideal situation would be for the PyCrypto-specific contributions to be placed into the public domain (i.e. all copyright interests be disclaimed). Alternatively, the same license that the Camellia reference implementation uses (i.e. 2-clause BSD) would be fine.

[Yoshisato YANAGISAWA (yanagisawa)]

Thank you for your reply.

I understood the goals in the next release. I will wait until PyCrypto attains the goals.
After that, I hope PyCrypto will include the Camellia block cipher, which is fast and strong enough.

According to your suggestion, I added copyright licensing statements for the PyCrypto-specific parts of my patch. I chose 2-clause BSD license for that.

Thank you in advance,

[Yoshisato YANAGISAWA (yanagisawa)]

I have updated the patch to support the HEAD of the python cryptography toolkit.
Will you review my patch?

Thank you in advance.

[Yoshisato YANAGISAWA (yanagisawa)]

Since the tests of my previous patch was too much, I replaced it to short tests.

[Yoshisato YANAGISAWA (yanagisawa)]

If there are any problems on my patch, please let me know.
Thank you.

[Darsey Litzenberger (dlitz)]

See: http://lists.dlitz.net/pipermail/pycrypto/2010q3/000264.html

I agree that Python developers should have access to Camellia, but Python does not need its own Camellia *implementation*; no new cipher implementations will be added to PyCrypto, and the existing ones will be replaced by wrappers around existing C cryptography libraries in the future.

I will keep this bug open, though, because we should remember to add Camellia support once the backend "engines" interface is completed.

[Yoshisato YANAGISAWA (yanagisawa)]

My patch includes Camellia implementation distributed from NTT website:
http://info.isl.ntt.co.jp/crypt/eng/camellia/engine.html
What I have implemented is a wrapper from pycrypto to the NTT's implementation, and a test code.
So, my patch is technically calling out to the existing library.

However, at the same time, I am also feeling the copy-and-paste problem in FOSS. Sometimes people should have their original implementation because of the license issue, and use compatible license source code. However, it also may cause a bug chain of many hidden-related softwares.

I will wait your new backend engine implementation and rewrite my patch again.