Zinc: a new kernel cryptography API [LWN.net]

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 0:28 UTC (Wed) by areilly (guest, #87829)
Parent article: Zinc: a new kernel cryptography API

What does "not an API at all; it's just functions" mean? Isn't an Application Programming Interface the name we use to describe the function signatures of the functions we expect applications to use to call our code?

I'm guessing that he means that the design isn't using some opaque state object that needs to be initialized and configured first, and that's lovely, but having one of those isn't a necessary part of being an "API", as far as I know.

Also: crypto off-load "engines" aren't just for phones, and aren't (I suspect) going away. If your "not an API" can't use them, then there will be grief sooner or later, I suspect.

to post comments

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 2:45 UTC (Wed) by k8to (guest, #15413) [Link] (6 responses)

I don't think you're wrong. Still, when I hear "API" I think of a ball of poo with parts that are poorly co-ordinated, opaque objecty things with no clear meaning, and things like close() or shutdown() functions that when you read them you find out do nothing. Oh and with some kind of error struct with 3 items all of which are numbers, none of which are documented outside the source code.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 2:54 UTC (Wed) by pj (subscriber, #4506) [Link] (5 responses)

Don't guess. Check out the 4.17 Crypto API docs in all their glory... and see what you think.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 4:15 UTC (Wed) by robert.cohen@anu.edu.au (subscriber, #6281) [Link]

That is an example of an API and yes it contains opaque blobs.

But that doesnt mean that all API's have to contain opaque blobs.

I would agree that the set of mechanisms that are used to programatically access the functionality of a package are the API of the package.

Just because there are many bad complicated API's out there doesnt mean all API's have to be confusing and complicated.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 4:15 UTC (Wed) by WolfWings (subscriber, #56790) [Link]

I mean for doing one-off encryption tasks with fixed blocks of data, or PBKDF2? The existing Linux Crypto API is pretty easy to use for that.

There's no scatter-gather needed or anything beyond basic socket handling (socket, bind, setsockopt, accept, write/sendto, read/recvfrom) but it's half the speed or slower than other approaches due to all the resulting syscalls in testing PBKDF2 for example, versus a standalone library. Upside? It's <800 bytes compiled for a full PBKDF2 implementation w/ proper error checking and fail-out.

But for a constant-stream-of-data system like a VPN or if you're trying to go As Fast As Possible? Yeah, it's sucky complexity once you hit using the scatter-gather functions instead or try to gin things up with zero-copy.

The existing kernel crypto API is meant to avoid having to roll your own libraries, and get faster versions if they're available, but it's got a lot of fixed overhead either in code complexity to make it scream, or syscall count if you don't care about speed.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 4:28 UTC (Wed) by k8to (guest, #15413) [Link] (2 responses)

Full disclosure, when I wrote that, I was thinking of various corporate "REST" apis that are anything but REST, overly complicated java libraries that resort to XML to "simplify", and OpenSSL. It wasn't really meant as a comment on anything directly related, whether apropos or not.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 17:20 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

API has a technical meaning: Application programming interface. This can be anything. Eg open, close, read, write, lseek, ftruncate are the basic UNIX file access API and they're all "just functions". There' also "an API" for network configuration which is build on top of AF_NETLINK sockets which is a rather different animal (and not a particularly cute or pretty one).

API is also a marketing term. Then, it means "we do stuff on the web and we're so absoluetely MODERN! that we won't even know what until next week!" (presumably, this usage is meanwhile somewhat dated).

:->

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 20:44 UTC (Wed) by k8to (guest, #15413) [Link]

I'm having trouble relating this comment to mine. I described my personal associations for the term, and you seem to be defining the term.

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 15:16 UTC (Wed) by mageta (subscriber, #89696) [Link] (2 responses)

He seem confused about this himself:

> So Zinc's approach, ..., is not to be an API at all ...
> ...
> Donenfeld's response was that he didn't like the idea of "polluting" the Zinc API ...

I don't completely understand what the phobia with the acronym API is all of a sudden?! Is this a thing now? People not wanting to use something because its called an API?

Coming from s390 I also disagree with the notion that Crypt-Offloading is something only for Android. Offloading is also done one the "opposite" of the spectrum, and isn't going to go anywhere. Building something on top of Zinc to handle that will help exactly how, if the rest of the world calls Zinc functions and not your stuff on top?

Zinc: a new kernel cryptography API

Posted Nov 7, 2018 18:01 UTC (Wed) by drag (guest, #31333) [Link]

I am guess that 'API' means something more specific and formal in the context of the kernel. The second quote then was him making a mistake and slipping back to the more generic meaning.

Zinc: a new kernel cryptography API

Posted Nov 8, 2018 6:53 UTC (Thu) by cyphar (subscriber, #110703) [Link]

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...

Zinc: a new kernel cryptography API

Posted Nov 8, 2018 8:57 UTC (Thu) by nhippi (subscriber, #34640) [Link]

I think the word API is misused here. I think what he is arguing is that midlayers are bad and helper functions are good.

The problem with midlayers being that you have to buy into them wholesale. If the framework doesn't fit your usecase, you have to either workaround it or get hooks implemented in the midlayer. And since it's a common layer, you can't just implement the hook *you* need - you need to negotiate with the midlayer maintainer a version that supports all hypothetical future use scenarios.

In the helper world, the API is just helper functions you can use, and if the helpers are not helpful for you, you just write your own function instead.

Zinc: a new kernel cryptography API

Posted Jan 9, 2020 22:03 UTC (Thu) by zimaalsu (guest, #136573) [Link]

Whats the differences from easync and other?