Date: Sat, 28 May 2016 16:19:12 -0400 From: Eric McCorkle <eric@metricspace.net> To: Alan Somers <asomers@freebsd.org> Cc: Allan Jude <allanjude@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org> Subject: Re: EFI GELI support ready for testers Message-ID: <F8B06B42-2283-4995-A9C5-7A62C52CC182@metricspace.net> In-Reply-To: <CAOtMX2h1XsG%2BMwpznXr2Hhiwe4-qi16J8%2BsGniOJsNQmOD%2BVVQ@mail.gmail.com> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> <B9C67D9B-6FF9-4F54-A1FD-EB17378B80D4@metricspace.net> <CAOtMX2h1XsG%2BMwpznXr2Hhiwe4-qi16J8%2BsGniOJsNQmOD%2BVVQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I see. They're part device interface, part software crypto implementation. I guess the question is, does the software crypto *have* to live there, or could it be in a separate library? I'm less inclined to trust OpenSSL completely these days, and it certainly is a beast to integrate into anything. Some compelling alternatives have emerged in the wake of heartbleed. Off the cuff, I'd say NaCl is a good option: it's public domain and it's got some big names in crypto attached to it. But I don't know enough to say for sure if it could do what I proposed. On May 28, 2016 1:24:55 PM EDT, Alan Somers <asomers@freebsd.org> wrote: >On Sat, May 28, 2016 at 9:23 AM, Eric McCorkle <eric@metricspace.net> >wrote: >> >>> On May 28, 2016, at 10:27, Allan Jude <allanjude@freebsd.org> wrote: >>> >>> The final version of my geliboot took an extra effort to reuse the >AES >>> code from sys/crypto/rijndael and sys/opencrypto and GELI directly >from >>> sys/geom/eli to avoid maintaining a separate copy of that code in >sys/boot >>> >>> Hopefully the work I did to make sys/opencrypto and sys/geom/eli >more >>> reusable outside of the kernel will make it easier for Eric to do >the >>> same for the EFI version. >> >> It did indeed make things easier, though I think there is potential >for work to be done on the crypto framework. It looks like the crypto >framework has kind of accumulated code over time from different sources >and has become somewhat disorganized. There seem to be two codebases >(crypto and opencrypto), and multiple differing implementations for >some ciphers. I ran into this when trying to figure out how to add >Camellia support. There's a usable interface for AES CBC/XTS, but not >Camellia CBC. There are also some insecure ciphers (DES, RC4, etc) in >there, some more modern ciphers (like chacha20) are missing, and it's >possible to implement ciphers other than AES using AESNI/AVX >instructions to achieve hardware acceleration. >> >> It also ought to be simpler to share crypto code between kernel, >boot, and userland, imo. In theory, one could have a single library >(with multiple compilations for different ABIs) that could be >statically linked into the kernel and boot loaders, and also installed >in to the base OS. >> >> I'm not sure if there's any plans for crypto, but it might be worth a >discussion. >> >>> >>> The motivation for the EFI version is the same, ZFS boot >environments, >>> plus the obvious security advantages of having the kernel stored >>> encrypted rather than not. >>> >> >> The ability to have a single ZFS filesystem is indeed a motivator for >the EFI work. I forgot to mention it because my personal motivations >are strongly focused on security and tamper-resistance. > >The problem with opencrypto is that it was written when crypto >accelerators lived on PCI cards and were treated as shared resources. >That's why userland programs wishing to use opencrypto have to send >all of their data into the kernel. It's a very inefficient way of >using CPU-resident accelerators like AESNI and Padlock. For clients >within the kernel, it's not so bad. It adds a few extra stack frames >and a lot of code but there are no additional data copies. crypto(3), >OTOH, is part of OpenSSL. AFAIK it doesn't have the data copies >problem, but it's still quite complicated. ken@ once tried to build >OpenSSL into the kernel but gave up because it has too many >dependencies. > >So neither of these libraries is suitable for use in both kernel and >userland. I don't know of any that is (though I haven't looked). > >-Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8B06B42-2283-4995-A9C5-7A62C52CC182>