In the previous article we looked at the two most interesting crypto toolkits. What else is out there? A lot.
Cryptlib: Peter Gutmann’s cryptlib library (with Python bindings)
- Official description
- A powerful security toolkit that allows even inexperienced crypto programmers to easily add encryption and authentication services to their software. The high-level interface provides anyone with the ability to add strong security capabilities to an application in as little as half an hour, without needing to know any of the low-level details that make the encryption or authentication work.
- Home Page
- http://www.cryptlib.com/, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
- Source Repository
- None (the source is distributed a .zip archive)
- Peter Gutmann
- BSD-like, GPL-compatible, OSI-approved Open Source license
- Commercial license for closed source use or for use in products with a total gross revenue of over US$5,000.
- Latest Version
- 3.3.3 (September 3, 2009)
I can’t help myself. This is a totally awesome toolkit. What strikes me the most is the documentation. Calling it “rich” would be an understatement. It’s filthy rich, with a 330-page user manual and a 420-page technical reference manual. The documentation covers every aspect of cryptlib’s functionality, contains tons of copy/paste-able examples, and exposes the design and internals of cryptlib itself, including the cryptlib security model. In addition, the technical manual provides background information to help users understand the security foundations. This isn’t surprising. The author, Peter Gutmann, is a renowned security researcher at the University of Auckland, New Zealand. This toolkit is concentrated expertise — the very essence of computer security captured in code. His home page has a whole lot of cryptography and security materials, including the godzilla crypto tutorial, totalling 973 slides. By the way, the New Zealand origins of this toolkit is quite an asset in itself. cryptlib is free of export control limitations and may be used anywhere in the world.
From the technical point of view, cryptlib is one of the most comprehensive toolkits out there. The set of implemented algorithms includes pretty much everything, with one annoying omission: elliptic-curve encryption is still under development. Unfortunately, there is no indication that ECC will appear in the upcoming 3.3.4 release. Among other things, cryptlib has full support of S/MIME (CMS/PKCS#7), PGP/OpenPGP, and SSH/SSL/TLS, has a plug-and-play PKI interface, and even features its own Certificate Authority engine. Cryplib has an internal, cryptographically secure entropy source based on a custom random pool implementation which can be extended with /dev/random, EGD, or PRNGD-style drivers. Also, it supports external hardware random generators. Almost any imaginable hardware crypto device is supported. cryptlib itself runs perfectly well on embedded systems, including those with limited functionality — even on ARM7 processors. Needless to say, cryptlib is compliant with an impressive list of national and international security standards. Now, something really shocking: the toolkit is officially supported on approximately forty (yes, 40) different operating systems, including the most obscure realtime, embedded and mobile OS’es. Out of the box, it can be used from six different programming languages, including Python.
cryptlib has a layered architecture. It contains a series of layers that provide each level of abstraction, with higher layers building on the capabilities provided by the lower layers.
Of course, high-level functions for data enveloping, session control and certificate management are presented. The high-level interface hides most of the implementation details, and uses operating-system-independent encoding methods that make transferring secure data from one environment to another a snap.
Is everything perfect with cryptlib? Unfortunately, no. The Python interface is not quite Pythonic. It really feels like a C API wrapped with a generated layer, which in fact it is. I believe that for wider adoption a new wrapper, crafted by hand, is absolutely necessary. There is also no way to write extensions in Python. Does it matter? With such a complete feature set, not that much. Another problem is extensibility on the C level. The only way of adding new algorithms is patching the source code and recompiling. It significantly reduces flexibility, but the reward comes with much improved integrity and overall security. Again, is that a problem if almost everything imaginable is included? I really don’t know, although OpenSSL’s approach (loadable engines) makes me feel better. I had problems using cryptlib from Python on my 64-bit Mac Book Pro. I hope this will be fixed in the next release. Although cryptlib is an opensource project, the development process is far from open. There is no publicly observable repository, so there is no way to see how and where the development is going. There is not even a bug tracking system. As a side note, it is amazing how un-opensource a project feels these days if it is not on github. Seriously, the opaqueness of the development process seems to me a big problem and a probable reason for slow adoption.
If you’re into crypto, try this toolkit. To say the least it’s worth looking at. What I really don’t understand is why such a good product is so little known.
Title photo courtesy of Darwin Laganzon on Pixabay.