Zinc: a new kernel cryptography API

While I wholeheartedly sympathize with the observation that the Linux crypto API has much room for improvement (CRYPTO_ALG_ASYNC indeed - and the documentation is certainly in need for some work) and I'm working on making it better (https://www.redhat.com/archives/dm-devel/2017-October/msg...), some of the things stated in the article about that API are not accurate, or at the very least, seem to indicate a lack of understanding about the reasoning behind them.

For example: "The key you're using ends up attached not to the object you just allocated, but to the global instance of the algorithm in question, so if you want to set the key you must take a mutex lock before doing so, in order to be sure that someone else isn't changing the key underneath you at the same time."

This is incorrect. The key is indeed associated with a transformation object, analogous to a security session and usually refereed to as tfm for short, while actual encryption/decryption is done on a request object, which is derived from a transformation object. However, this transformation object is NOT a singleton. You can have as many of them as you like and, should you wish, can have a 1:1 association between a transformation and a request, and therefore have no need for a mutex or other locking arrangement.

The reason for this arrangement becomes obvious, by the way, once you consider a protocol such as IPsec, where a single session, which uses a specific key, may have several outstanding independent requests associated with it, corresponding to different IPsec packets.

In a similar way, the statement "When you've got it set up and want to encrypt something, you can't simply pass data by address. You must use scatter/gather to pass it, which in turn means that data in the vmalloc() area or on the stack can't just be encrypted with this API. " misses the mark, because it fails to note WHY this is the case - some of the encryption transformation providers in the kernel are hardware based and use DMA to access the memory to be operated on. Performing DMA to/from memory obtained from stack area is a bad idea and will not work. At the same time, it is possible to feed the crypto API memory obtained from vmalloc() - but it needs to be done with care (for example - https://patchwork.kernel.org/patch/10573051/).

Once again, the reason is that some of the transformation providers are HW elements that access the data via DMA. In fact, the Linux Crypto API used to have a separate API that allowed you to provide simple pointers to virtually addressed memory (blkcipher) and this interface was deprecated and removed.

Furthermore, these HW based transformation providers do more than simply provide "acceleration" - some of them (such as the one included in s390 and Arm CryptoCell of which driver I am the maintainer of) allow the decryption and encryption of data where the actual keys are sealed in hardware and therefore are significantly more difficult to steal, even in the face of a security breach - a capability that is even more important in these days of Spectre and Meltdown, than ever before.

In summary, the Linux Crypto API does need some tender love and care and the work and feedback from brilliant people such as Jason Donenfeld is highly appreciated. However, when doing so it is critical to understand why the API looks the way it does. Otherwise, you may end up either missing lessons learned in the past.

Cheers,
Gilad Ben-Yossef <gilad@benyossef.com>