Zinc: a new kernel cryptography API

I would recommend that everyone in this thread who is confused go and watch the Kernel Recipes talk[1], where he explains in quite a bit of depth what he means by "API" (which I agree is not the best way of phrasing what the problem is with the API). This information is actually given in the article, though it is given in quite a dense paragraph that you might miss it:

> The first step with the existing API is to allocate an instance of a cipher "object". [...]

The short version is that the current crypto API is very abstracted and "enterprisey" in how it works. Here is an incomplete list of problems and confusing behaviour from what I understand:

* In order to specify an algorithm there's a weird meta-language that is parsed -- stuff like "gcm(aes)" to represent AES-GCM.
* You need to use scatter-gather even for encrypting a single buffer -- meaning you can't use stack values.
* Additional data is apparently stored in the same buffer as the plaintext-to-be-encrypted.
* You need to allocate memory each time you want to encrypt something, and once per-key.
* Keys are global -- despite there being an object you are dealing with -- and thus you need to take a mutex if you want to change what key you're using or allocate a new encryption context for each key.
* In order to use the API synchronously you need to pass the flag CRYPTO_ALG_ASYNC!
* Many internals of the crypto API have slowly leaked to lib/ because people want to use the crypto but don't want to use the crypto API.

I'm not familiar with using the crypto API at all, but if even half of these are significantly true then I agree with Donenfeld that this API really has a lot of problems. I'm sure the reason it's so complicated and convoluted is because of crypto hardware off-load requirements -- but that doesn't mean that everything in the kernel should be forced to go through these hoops if hardware off-load is not actually useful for their usecase.

Zinc is literally just a bunch of functions, which form an API, but is not in any way abstracted like the crypto API. Donenfeld specifically says that this is not a new idea, it's just taking an already existing idea and putting it in the kernel (just use functions, forget abstracting away different crypto implementations).

[1]: https://kernel-recipes.org/en/2018/talks/zinc-minimal-lig...