From owner-freebsd-security@freebsd.org Fri Oct 27 00:29:10 2017 Return-Path: Delivered-To: freebsd-security@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 B4B41E56CEF; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 918E86F945; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7E7A912D3; Fri, 27 Oct 2017 00:29:08 +0000 (UTC) To: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Crypto overhaul Message-ID: Date: Thu, 26 Oct 2017 20:29:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:29:10 -0000 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.