Hi Herbert, On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > My proposal is to merge the zinc interface as is, but to invert > how we place the algorithm implementations. IOW the implementations > should stay where they are now, with in the crypto API. However, > we will provide direct access to them for zinc without going through > the crypto API. IOW we'll just export the functions directly. Sorry, but there isn't a chance I'll agree to this. The whole idea is to have a clean place to focus on synchronous software implementations, and not keep it tangled up with the asynchronous API. If WireGuard and Zinc go in, it's going to be done right, not in a way that introduces more problems and organizational complexity. Avoiding the solution proposed here is kind of the point. And given that cryptographic code is so security sensitive, I want to make sure this is done right, as opposed to rushing it with some half-baked concoction that will be maybe possibly be replaced "later". From talking to folks at Plumbers, I believe most of the remaining issues are taken care of by the upcoming v9, and that you're overstating the status of discussions regarding that. I think the remaining issue right now is how to order my series and Eric's series. If Eric's goes in first, it means that I can either a) spend some time developing Zinc further _now_ to support chacha12 and keep the top two conversion patches, or b) just drop the top two conversion patches and work that out carefully with Eric after. I think (b) would be better, but I'm happy to do (a) if you disagree. And as I mentioned in the last email, I'd prefer Eric's work to go in after Zinc, but I don't think the reasoning for that is particularly strong, so it seems fine to merge Eric's work first. I'll post v9 pretty soon and you can see how things are shaping up. Hopefully before then Eric/Ard/you can provide some feedback on whether you'd prefer (a) or (b) above. Regards, Jason
