Crypto overhaul

[Eric McCorkle]

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.