Crypto overhaul

[John Hein]

Eric McCorkle wrote at 20:29 -0400 on Oct 26, 2017:
 > I was going to wait a bit to discuss this, but it's very pertinent to
 > the trust infrastructure I described earlier this week.
 > 
 > There was a good bit of discussion at vBSDCon about a possible crypto
 > overhaul.  This is my understanding of the current situation:
 > 
 > * Userland crypto support is provided by OpenSSL, of course.  My sense
 > is that there's a general dissatisfaction with OpenSSL, but that there's
 > a nontrivial effort required to liberate userland from it.
 > 
 > * The kernel has sort of two crypto APIs: crypto and opencrypto.  The
 > design of these APIs seems to be something of older hardware crypto
 > architectures and export restrictions.  This is difficult to extract
 > from the kernel (and say, embed into the boot loader).
 > 
 > * BIOS geli pulled the AES implementation out of opencrypto.  This was
 > due in a large part to the size restrictions on BIOS loaders.
 > 
 > * As a bridge measure, I've introduced boot_crypto into the EFI loader,
 > in order to support GELI.
 > 
 > At vBSDcon, there seemed to be a consensus that this situation is too
 > fragmented.  Moreover, it makes life difficult for anyone (like me) who
 > wants to do crypto-related projects.
 > 
 > 
 > A couple of options were discussed at vBSDcon.  The two that seemed to
 > come to the forefront were BearSSL and LibreSSL.  There seem to be some
 > advantages and disadvantages both ways:
 > 
 > * LibreSSL is mature software with staff and support from another BSD
 > (OpenBSD), they've done some really good work, and have a definite
 > long-term roadmap.  I'm not sure to what extent it could be easily
 > embedded into a kernel and bootloader, though.
 > 
 > * BearSSL's design seemingly lends itself to acting as a userland,
 > kernel, and bootloader library.  On the other hand, it's new (which
 > means it will need to be reviewed by crypto experts and thoroughly
 > tested), and has one developer at this point.
 > 
 > 
 > I think it's worth discussing and investigating these options further at
 > this point.

What's the overhaul goal here?  There's basic crypto libraries with
symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium,
openssl's libcrypto).  There's libraries that add support for SSL/TLS
& X.509 certificates and such.  There's stuff to support using
crypto hardware (accelerators, secure crypto token storage devices).

And is the thought to [eventually] replace openssl in base with
something lighter perhaps?

I assume we're looking for bsd, isc, mit, etc., style licenses only.