Date: Fri, 27 Oct 2017 07:46:07 -0600 From: "John Hein" <jh-fbml@snkmail.com> To: "Eric McCorkle" <eric@metricspace.net>, <freebsd-arch@freebsd.org>, freebsd-security@freebsd.org, <freebsd-hackers@FreeBSD.org> Subject: Re: Crypto overhaul Message-ID: <4207-1509111977-98568@sneakemail.com> In-Reply-To: <dc08792a-3215-611c-eb9f-4936a0d621f9@metricspace.net> References: <dc08792a-3215-611c-eb9f-4936a0d621f9@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4207-1509111977-98568>