Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Oct 2017 11:00:04 +0100
From:      Ben Laurie <ben@links.org>
To:        Eric McCorkle <eric@metricspace.net>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>,  "freebsd-security@freebsd.org security" <freebsd-security@freebsd.org>,  "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Crypto overhaul
Message-ID:  <CAG5KPzws=jmF2wLeEAz8Lzn7Ugude=0w5neoQjeDjYnGtJpS9Q@mail.gmail.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
On 27 October 2017 at 01:29, Eric McCorkle <eric@metricspace.net> wrote:
> 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.

Have you considered BoringSSL?

> * 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.

OpenSSL includes (and is used for) lots of crypto that is not used in
SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be
used to replace all uses of OpenSSL.

>
>
> I think it's worth discussing and investigating these options further at
> this point.
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5KPzws=jmF2wLeEAz8Lzn7Ugude=0w5neoQjeDjYnGtJpS9Q>