Thread (61 messages) 61 messages, 10 authors, 2018-09-19

Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2018-09-13 17:35:45
Also in: lkml, netdev

On Thu, Sep 13, 2018 at 5:04 PM Ard Biesheuvel
[off-list ref] wrote:
quoted
The code still benefits from the review that's gone into OpenSSL. It's
not modified in ways that would affect the cryptographic operations
being done. It's modified to be suitable for kernel space.
So could we please at least have those changes as a separate patch then?
I'll experiment with a couple ways of trying to communicate with
precision what's been changed from OpenSSL for the next round of
patches.
quoted
That's interesting. I'll bring this up with AndyP. FWIW, if you think
you have a real and compelling claim here, I'd be much more likely to
accept a different ChaCha20 implementation than I would be to accept a
different Poly1305 implementation. (It's a *lot* harder to screw up
ChaCha20 than it is to screw up Poly1305.)
The question is really whether we want different implementations in
the crypto API and in zinc.
Per earlier in this discussion, I've already authored patches that
replaces the crypto API's implementations with simple calls to Zinc,
so that code isn't duplicated. These will be in v4 and you can comment
on the approach then.
You are completely missing my point. I am not particularly invested in
the crypto API, and I share the concerns about its usability. That is
why I want to make sure that your solution actually results in a net
improvement for everybody, not just for WireGuard, in a maintainable
way.
Right, likewise. I've put quite a bit of effort into separating Zinc
into Zinc and not into something part of WireGuard. The motivation for
doing so is a decent amount of call sites all around the kernel that
I'd like to gradually fix up.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help