Re: Importing libraries for the kernel
Thor Lancelot Simon <[email protected]> Tue, 18 Dec 2018 08:53:54 -0500
| Newsgroups | gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.kernel,gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Dec 14, 2018 at 03:19:45PM +0100, Joerg Sonnenberger wrote: > On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote: > > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger <[email protected]> wrote: > > > > > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > > > > Before that, I want to ask about how to import cryptography > > > > libraries needed tor the implementation. The libraries are > > > > libb2[1] and libsodium[2]: the former is for blake2s and > > > > the latter is for curve25519 and [x]chacha20-poly1305. > > > > > > I don't really have a problem with Blake2s, but I have serious concerns > > > for doing asymmetric cryptography in the kernel. In fact, it is one of > > > the IMHO very questionable design decisions behind WireGuard and > > > something I don't want to see repeated in NetBSD. > > > > Can you clarify the concerns? > > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC We have an existing facility for doing slow cryptographic operations asynchronously in the kernel. Except where architectures have really fast, instruction-style hardware support for asymmetric crypto operations (and perhaps even there depending on operand size) this stuff should be done in a thread interfacing to the rest of the kernel through the existing opencrypto framework. That said, I believe we should have asymmetric crypto operations in the kernel for executable and security policy signing. In fact, I believe it strongly enough to have implemented it (interfaced via opencrypto as described above) twice -- but I don't own either implementation and thus can't contribute them. They did _not_ cause measureable performance problems of any kind, and though it is theoretically possible to do this sort of thing via a tightly-protected userspace helper process, I prototyped that too and it gets very ugly, very fast -- the in-kernel way with a thread is, I believe, better. -- Thor Lancelot Simon [email protected] "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov