From owner-freebsd-hackers@freebsd.org Sat Oct 28 08:17:52 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 32188E5ED4F; Sat, 28 Oct 2017 08:17:52 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D26167A53; Sat, 28 Oct 2017 08:17:51 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v9S8Hodv018008 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v9S8Hogh018007; Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Oct 2017 01:17:50 -0700 From: John-Mark Gurney To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028081750.GG42467@funkthat.com> Mail-Followup-To: Eric McCorkle , "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) 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: Sat, 28 Oct 2017 08:17:52 -0000 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."