The state of my exposure to cryptographic libraries
2016-09-30 14:56 by Ian
This is a quick overview of the cryptographic libraries I have deep experience with.
This is my only exposure to Cryptography in Java, apart from the platform APIs in JavaEE and Android. This library was integral to my work at CellTrust, and I used it consistently for at least 2 years. It is FIPS certified, and free, which is a rare combination of traits.
The old standby... The only other library of which I am aware that is both open-source, and FIPS certified. Which is one reason that so many serious-about-compliance projects use it. It was a nightmare to learn when I started using it in 2010, and has a widely-fragmented code base.
That last point needs elaboration... At one point, I had four independent installations on my Nexus-S (that I was aware of). All four were different versions.
- The android base (the only one that was a dynamic library).
- A static build that someone else's OSS project brought along for its own use.
- The static version with parallel crypto engine that I rolled into a ROM to support the OpenVPN module.
- My FIPS-capable build that I used to validate CAVS on android.
OpenSSL is battle hardened, well understood, reliably-present on big systems, and is going to be with us at-least the next 10 years. But if you are picking this stuff up for the first time, I would recommend you learn something else (unless you need FIPS-compliance, in which case, I can save you some pain).
This was the easiest-to-port crypto lib I've seen. And while many other C libraries are easy to port to new platforms (almost by definition), this one gives excellent documentation and well-described hooks into every platform-specific operation that cryptography might depend upon. Moreover, it has an excellent modularity strategy that allows you to include as much support as you want, provided you can afford the basic abstraction costs. This is my new default pick for C/C++ cryptography. I've also forked an independently-maintain a nodejs wrapper for it.
- Inability to access buffers byte-wise.
- Narrow support. Only AES-CBC, or only a specific HMAC.
- Wrapper around a native library. If I am using JS for crypto, it means I'm probably targeting a browser.
I finally settled on crypto-js as the one I think least-bad.
I've used this one in both PHP and C [ closed-source code :-( ], and it's fairly easy to use. I'd recommend it if you are starting out with cryptography, as it has a plush set of high-level APIs that you can use that require minimal knowledge of the library's internal arrangement, and even without broad knowledge of cryptographic algorithms.
Like OpenSSL, this library is written in C, and has been hard-forked all over the place. If all you need from cryptography is DTLS, and you need it inside a mint tin, then it's great. But it has limited cipher suite support, and the manner in which they are supported is evidence that modularity took a back-seat to size.