tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Importing libraries for the kernel



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 <joerg%bec.de@localhost> 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	                                     tls%panix.com@localhost
  "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


Home | Main Index | Thread Index | Old Index