[pfranz]

That's great to hear, but I wonder if anyone has insight on the rest of the article. Is this Zinc API a prerequisite for WireGuard to be included? Is the fact that Zinc won't support hardware encryption a no-go or is the expectation they give reasonable? Has the kernel had any large API refactoring similar the crypto/Zinc (I would assume it has)--how did they play out?

[caf]

There seems to be broad agreement for the need for a set of software crypto implementations with a straightforward synchronous, static dispatching API. The discussions seem to be mainly around code organisation and plumbing that API as an underlying implementation used by the dynamic dispatch asynchronous crypto API.

[zx2c4]

Right. So basically v2 of the Zinc patchset will address the nice points brought up on the list, and I think things should proceed nicely.

[rurban]

Jason: Any word on the name yet? My concern is the confusion with the existing my minizinc and flatzinc project, a standard constraint modeling language, which has nothing to do with crypto. There should be some better name for the Linux crypto lib.

[majewsky]

So what? Name clashes happen all the time. Before seeing this comment, I had never heard of minizinc and flatzinc. In fact, if you had asked me if Zinc clashes with anything, I'd have thought of Tinc (which is a VPN product, so roughly in the same space).