Hi Eric, On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > It's not really about the name, though. It's actually about the whole way of > thinking about the submission. Is it a new special library with its own things > going on, or is it just some crypto helper functions? It's really just the > latter, but you've been presenting it as the former No, it really is its own thing with important differences from the present crypto api. Zinc's focus is on simplicity and clarity. To the extent that we're at all tangled with the current crypto api, the goal is to untangle as much as possible. It intends to be a small and lightweight set of routines, whose relationships are obvious, and with this direct and to the point organization, as well as work with the larger cryptography community and with academia to invite collaboration. With this comes a different way of maintaining it, with higher standards and a preference for different implementations than the current situation. With Zinc, you have an obvious series of C function calls composing the whole thing, without complicated indirection. It's something that could be trivially lifted out into a userspace library, and used broadly, for example -- something I'll probably do at some point. That's a bit of a design change to the current crypto api, and sprinkling some direct function calls within the current crypto api's complicated enterprise situation would only kick the can further down the road, as much complexity would still remain. The goal is to move away from behemoth enterprise APIs, and large and complex codebases to a simple and direct way of doing things. This desire to untangle, to start from a simpler base, and to generally do things differently means it will go into lib/zinc/ and include/zinc/ and have different maintainers. Jason
