Hi Zooko, I have been realizing that I probably need something else than Crypto++. Eventhough I liked Crypto++ design (as former C++ coder), when trying to wrap it I observed that it is in fact quite "unwrappable" in a sense that "just" exporting different variants of DES (i.e. ECB, CBC, 1,2,3 keys, etc) generates a dll over 2MB of size. And this happened when linking against dynamic runtime and dynamic boost_python. I believe it is because everything has to be generated as new type and it seems each type imports complete backend with itself. Also it is not possible to easily expose template typed types into Python, even though originally it looked like a good idea with boost. But boost seems can do only as much, and when it fails it is quite hard for me to figure out why.
Adding some cryptic errors about alignment (which I mentioned before) was not very encouraging either. And finally, I found out that I need more high level stuff to parse all different kinds of ASN1 encoded material for which I did not find direct support in Crypto++. So, at the end I ended up with M2Crypto (openssl wrapper). The only thing I was not able to port was CBC-MAC calculation, for which I still use my boost wrapped implementation and wonder if I should "reimplement" it in Python just for the sake of getting rid of boost&Crypto++ completely. To be honest, I was not very happy with either Crypto++ or M2Crypto, considering scarce documentation for both projects, where especially in case of Crypto++ the advice to "read (self documented) code" did not work for me. I also had a look at Botan, but eventually I passed on it as well because it was lacking some features and would lead to having at least one other library. Considering tahoe-lafs, this was actually first project I considered, but as the others, it did not have everything I needed. It is a shame that there is no industrial crypto lib implementation for Python (possibly the wrapper around of some proven one native implementation). Richard On Thu, Mar 31, 2011 at 4:00 AM, Zooko O'Whielacronx <[email protected]> wrote: > Hi there. I don't know about the cause of your problems with Crypto++ > and boost::python. If you have gotten it to work to your satisfaction > then could you please share the recipe? > > You might also be interested in http://tahoe-lafs.org/trac/pycryptopp > . Another alternative is the Botan crypto library > (http://botan.randombit.net/ ) which comes with Python wrappers > created with boost::python maintained by the author of Botan. If you > get *that* working, I'd like to hear about it, too. > > Regards, > > Zooko > > On Fri, Feb 11, 2011 at 9:51 AM, Richard Musil <[email protected]> > wrote: >> Recently I have been trying to implant Crypto++ into Python using >> boost::python. After ironing few things about dynamic CRT & static >> linkage I was able to build the thing. The only other thing I had to >> also do was changing alignment configuration in Crypto++ by adding >> >> #define CRYPTOPP_ALIGN_DATA(x) >> #define CRYPTOPP_DISABLE_X86ASM 1 >> >> into config.h just before >> >> #ifndef CRYPTOPP_ALIGN_DATA >> ... >> >> If I did not do that I observed following error when compiling my >> boost::python-ed module: >> >> ------ Rebuild All started: Project: CryptoPP_DLL, Configuration: >> Release Win32 ------ >> Deleting intermediate and output files for project 'CryptoPP_DLL', >> configuration 'Release|Win32' >> Compiling... >> stdafx.cpp >> Compiling... >> CryptoPP_DLL.cpp >> E:\boost\include\boost-1_45\boost/python/converter/ >> as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': >> formal parameter with __declspec(align('8')) won't be aligned >> E:\boost\include\boost-1_45\boost/python/ >> to_python_converter.hpp(88) : see reference to class template >> instantiation >> 'boost::python::converter::as_to_python_function<T,ToPython>' being >> compiled >> with >> [ >> T=DES_CFB_ENC, >> >> ToPython=boost::python::objects::class_cref_wrapper<DES_CFB_ENC,boost::python::objects::make_instance<DES_CFB_ENC,boost::python::objects::value_holder<DES_CFB_ENC>>> >> ] >> >> ------- >> >> this is just beginnig of the build log which is quite windy going on >> on next 4500 lines complaining about a lot of things, but I believe >> the culprit is here. >> >> I am not at all familiar with boost::python internals or Crypto++ >> internals to be able to judge whether the issue is cause by the one or >> the other, but I hope someone maybe would be able to shed some light >> on implications of alignment configuration and the change I did. >> >> I also found out (by trial and error) that I need to disable x86 asm, >> which originally I had expected to work with alignment being disabled >> (maybe just taking some penalty form un-aligned access.). >> >> Versions used: >> >> boost 1.45 (dynamic linkage with dynamic runtime) >> Crypto++ 5.6.1 (static linkage with dynamic runtime) >> Python 2.7.1 >> Microsof Visual C++ Express 2008 SP1 >> >> Richard >> >> -- >> You received this message because you are subscribed to the "Crypto++ Users" >> Google Group. >> To unsubscribe, send an email to [email protected]. >> More information about Crypto++ and this group is available at >> http://www.cryptopp.com. > -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
