It rained all night and most of the morning, and the temperature dropped to something humane for the first time all summer. I've taken a few days to relax, doing only the simplest mental work, and today I am ready to dig back in for the long haul.
I spent the morning browsing around at cryptographic libraries that I can use as substitutes for GNU PG & libgpgme. The choice of libgpgme developers to perform all the functions in their own processes (for the sake of 'security') leads to difficulty when trying to embed the library wholesale into an application. Static compilation - necessary for my middleware project - is not possible because libgpgme loads libgpg-error dynamically. At first glance libgpgme is very nice. The benefit of managing the private/public key pairs using GPG is very seductive. Then you start hitting the hick-ups and realize you're going to need something else. Enter
DMOZ.
All followers of search engines and search technologies have likely heard of DMOZ, but I wonder how many have used it. Typically, I don't run through their directory very often myself, but today was different. It could have spent 3 days using Google and never found more than two or three cryptographic libraries - and the majority of them would have been commercial. Browsing to the appropriate section in DMOZ lead to a dozen or more libraries, with at least a half dozen written for C/C++. I found a few candidates to look closely at, then narrowed it to down to a few prospects, now I'm looking at which one I should use.
Crypto++
I'm working with the crypto++ library right now and having issues. I can't say much for the C++ coding style. Files are named one thing and declare classes of different names :( I can say this: crypto punks are *apparently* not good programmers. Yeah, this package is NOT GCC 4 friendly.... too bad, I like the interface a lot.
Catacomb
Catacomb-2.0.0 has an autoconf script which doesn't recognize Mac OS X. :( Also there is zero documentation - not even an example folder or test set. :( The package also appears to be relatively young.... onto the next package...
Beecrypt
BeeCrypt compiles. The autoconf script allows the package to optimize itself for the CPU architecture. The package has Java & Python support in addition to C/C++. Plus the code is tight at ~276K and the library builds fast - 20x to 30x faster than GPG/libgpgme/libgpg-error do.
The C++ wrapper emulates Java's public key libraries, I guess that isn't a bad way to do things, but there seem to be few examples of how to use the package. I can use the Sun Documentation to get the basic gist of it, but the details vary. The only draw back to this package seems to be documentation and example code. No info or man pages provided, doxygen documentation is the only documentation provided.
The C++ wrapper is dependent on IBM's ICU libraries for unicode support. I'm not sure how I feel about this. ICU is big and takes a long time to compile. Frankly, I'm not entirely convinced it should be required.
Update: Well, not only is ICU required but it is linked dynamically.... and that is a deal breaker. The whole purpose of moving away from GPG + libgpgme + libgpg-error was to find a static crypto library. I'm looking into Nettle now. I have reservations about it because I don't think the Win32 support is good enough. I may just use beecrypt's C library without the C++ wrapper :( or I could put in the time to wright my own wrapper with no ICU or dynamic dependencies. Nettle
Nettle is used by LSH for its cryptographic needs. I think I'm going to go with BeeCrypt, but this might be a fall back. BeeCrypt is roughly 10 years old and has good compiler/platform support. Nettle is about 5 years old.
On another note...
Caolan McNamara out of Ireland points out the problem with anonymous enums under GCC 4, so I'm guessing the solution is to name the enums and refer to the enumerated types by their names.
