Date: Sat, 28 Oct 2017 01:17:50 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Eric McCorkle <eric@metricspace.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: Re: Crypto overhaul Message-ID: <20171028081750.GG42467@funkthat.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 this message on Thu, Oct 26, 2017 at 20:29 -0400:
> 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).
I wouldn't call them crypto and opencrypto.. There is the opencrypto
API, as documented by crypto(9), and then there are various undocumented
API's in sys/crypto that give direct software access to various hash and
cipher functions...
> * 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.
The opencrypto API is a very terrible API. There are lots of issues
w/ it, and it should be overhauled. The algorithm agility that it
provides is more complex than needed, and very few people need the
options it provides. It increases driver complexity to support the
many different ways that encryption and mac algorithms can be ordered...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171028081750.GG42467>