Remember Crimson ? Back in 2006, you know the year of the linux desktop😉, I started a new project/repo for people who wanted to contribute alternative cryptographic implementations for Mono (or .NET). That did not get much traction but the potential was there: Mono’s cryptographic stack (like .NET) is pluggable and simply waiting for plugins.
Fast forward to late 2011. Mono runs on more devices and architectures than ever before. Some of them have less memory and/or CPU power than most desktop PC had back in 2006. Often this does not matter but in some cases, like CPU intensive cryptography, that can hurt a lot. Even more frustrating when you realize that many of those devices have dedicated hardware to make some operations very fast while offloading the main CPU.
So where does this cool stuff hide ? In one word: kernel (think IPsec, VPN…)
Can userspace applications benefit from this ? Yes, by using /dev/crypto, also known as cryptodev. This expose the kernel cryptographic algorithm implementations (either the defaults or custom hardware-based drivers) to userspace.
Can Mono use this ? Of course. Both are pluggable architectures meaning that, under the right circumstances Mono, and your application, could be using hardware accelerated cryptography.
Just how much performance is there to gain ? Hard to say. That’s a common question and you can find all kind of benchmarks showing every kind of result: all of them true if you run their benchmarks, most false when you run your own applications. Keep in mind that:
- Performance largely depend on your working buffer size: the larger your buffers are, the most performance you’ll get;
- Sometime your application can control its buffer sizes (which makes it easy for benchmarking applications), sometime it can’t (e.g. network streams like SSL).
The buffer sizes are even more important when using Mono with native cryptography since it defines how many transitions will be done between managed and native code. Small buffers means more transitions, resulting in Mono managed implementations being faster than native – IOW you can slow down your application by using native code.
OTOH Mono (managed) performance won’t scale for long when using large blocks while it will grown much quicker when doing (less transitions for) native calls. Here is a graphic of hashperf‘s results on SHA1 (managed versus default, non-accelerated, kernel):
What does this means ? If you are hashing small structures or using small buffers (less than 100 bytes) then the managed SHA1 implementation will outperform the native cryptodev (Y axis units are MB/seconds) but once you use buffers over 256 bytes then the cryptodev will outperform the managed implementation (from 0.5x to 2.3x).
Next are cryptperf‘s results for AES (managed versus default kernel):
Again the same results. You’ll get better performance from the managed implementation on small buffers (smaller than 100 bytes) but it will quickly become advantageous to use the native AES (from 0.4x to 2.1x).
Conclusion: You have another set of benchmarks to contradict others😉 Seriously can real application really benefits from this ? Yes, if you control the cryptographic processing of your application you can get similar (or even better when accelerated) results of out this🙂
Many Linux distributions do not ship with
/dev/crypto enabled. You’ll have to install it yourself and also make sure it’s accessible to your application, i.e. adjust the permissions, like this:
$ cd cryptodev-linux-1.0
$ sudo make install
$ sudo insmod cryptodev.ko
$ ls -l /dev/crypto
crw------- 1 root root 10, 57 2012-02-26 14:30 /dev/crypto
$ sudo chmod 666 /dev/crypto
$ ls -l /dev/crypto
crw-rw-rw- 1 root root 10, 57 2012-02-26 14:30 /dev/crypto
Some Android devices, like my Vox tablet but not my Nexus S phone, do support
$ /opt/android/sdk/platform-tools/adb shell
# ls -l /dev/crypto
crw------- root root 10, 61 2012-02-26 14:25 crypto
Sadly its permissions only makes it available to root which pretty much kills its potential for better cryptographic performance with Mono for Android based applications😦