From owner-freebsd-hackers@freebsd.org Fri Oct 27 13:46:25 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95523E45788 for ; Fri, 27 Oct 2017 13:46:25 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [64.46.156.55]) by mx1.freebsd.org (Postfix) with ESMTP id E4D9865DAC for ; Fri, 27 Oct 2017 13:46:24 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from 206.168.13.214 by sneak2.sneakemail.com with SMTP; 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #2); 27 Oct 2017 13:46:18 -0000 Received: (sneakemail censored 4207-1509111977-98568 #1); 27 Oct 2017 13:46:18 -0000 Message-ID: <4207-1509111977-98568@sneakemail.com> Date: Fri, 27 Oct 2017 07:46:07 -0600 From: "John Hein" To: freebsd-hackers@freebsd.org To: "Eric McCorkle" , , freebsd-security@freebsd.org, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: References: Subject: Re: Crypto overhaul X-Mailer: Perl5 Mail::Internet v X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:46:25 -0000 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.