From owner-freebsd-security@FreeBSD.ORG Wed Nov 12 19:41:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F5F8DE7; Wed, 12 Nov 2014 19:41:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF1D7DD7; Wed, 12 Nov 2014 19:41:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sACJfBxU032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 11:41:11 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sACJfA3w032148; Wed, 12 Nov 2014 11:41:10 -0800 (PST) (envelope-from jmg) Date: Wed, 12 Nov 2014 11:41:10 -0800 From: John-Mark Gurney To: Vsevolod Stakhov Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141112194110.GX24601@funkthat.com> Mail-Followup-To: Vsevolod Stakhov , freebsd-security@freebsd.org, FreeBSD-Current References: <20141108042300.GA24601@funkthat.com> <545E6712.5060305@highsecure.ru> <20141108204538.GI24601@funkthat.com> <545E8904.6070109@highsecure.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <545E8904.6070109@highsecure.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Nov 2014 11:41:11 -0800 (PST) Cc: freebsd-security@freebsd.org, FreeBSD-Current X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:41:13 -0000 Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +0000: > On 08/11/14 20:45, John-Mark Gurney wrote: > >Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000: > >>On 08/11/14 04:23, John-Mark Gurney wrote: > >>>Hello, > >>> > >>>Over the last few months, I've been working on a project to add support > >>>for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is > >>>sponsored by The FreeBSD Foundation and Netgate. > >>> > >>>I plan on committing these patches early next week. If you need more > >>>time for review, please email me privately and I will make delay. > >>> > >>>The code has already been reviewed by Watson Ladd (the software crypto > >>>implementations) and Trevor Perrin (the aesni module part) and I have > >>>integrated these changes into the patch. > >>> > >>>There are two patches, one is the changes for OpenCrypto and the test > >>>framework. The other is the data files used by the test framework. > >>>The data is from NIST's CAVP program, and is about 20MB worth of test > >>>vectors. (I just realized, should we look at compressing these on > >>>disk?) > >>> > >>>Main patch (192KB): > >>>https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch > >>> > >>>Data files (~20MB): > >>>https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch > >>> > >>>A list of notable changes in the patch: > >>>- Replacing crypto(4) w/ NetBSD's version + updates > >>>- Lots of man page updates, including CIOCFINDDEV and crypto(7) which > >>> adds specifics about restrictions on the modes. > >>>- Allow sane useage of both _HARDWARE and _SOFTWARE flags. > >>>- Add a timing safe bcmp for MAC comparision. > >>>- Add a software implementation of GCM that uses a four bit lookup > >>> table with parallelization. This algorithm is possibly vulnerable to > >>> timing attacks, but best known mitigation methods are used. Using > >>> a timing safe version is many times slower. > >>>- Added a CRYPTDEB macro that defaults to off. > >>>- Bring in some of OpenBSD's improvements to the OpenCrypto framework. > >>>- If an mbuf passed to the aesni module is only one segment, don't do > >>> a copy. This needs to be improved to support segmented buffers. > >>>- Remove the CRYPTO_F_REL flag. It was meaningless. It was used but > >>> did not change any behavior. > >>>- Add function crypto_mbuftoiov to convert an mbuf to an iov. This > >>> also converts the software crypto to only use iov's even for a simple > >>> linear buffer, and so simplifies the processing. > >>>- Add a dtrace probe for errors from the ioctl. > >>>- Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) > >>> of AES-GCM and future AEAD modes. > >>> > >>>Future improvements: > >>>- Support IV's longer than 12 bytes for GCM. > >>>- Make AES-NI support segmented buffers (iov or mbuf) so multisegmented > >>> inputs don't have to be copied. > >> > >>I have the question regarding to the algorithm of GF field calculations > >>used in the proposed implementation: why not use the recent researches > >>in GCM calculations, e.g. described in [1], for further speed > >>optimizations? > >> > >>[1] - https://eprint.iacr.org/2013/157.pdf > > > >The paper you linked to does not describe a new way of calculating > >GHASH, but evalutation of a bug in their implementation using the > >PCLMULQDQ instruction... > > > >If you mean, why don't I use OpenSSL's code? The reason is that their > >code is a perl script that generates assmebly... We don't have > >perl in base.. and I didn't want more assembly in our tree (see below).. > > > >Instead, I decided to use code from Intel's whitepaper: > >Intel® Carry-Less Multiplication Instruction and its Usage for > >Computing the GCM Mode > > > >I didn't use their assembly version because I wanted to have > >maintainable code, and also the same code can be used on both i386 > >and amd64 arches.. This turns out to also be a good thing, as when > >I add segmented buffer support, it'll be much easier to add to the C > >version, and I only have to do the work once for two arches... > > > >Also, the software GF library that I wrote is using state of the art > >algorithms... An OpenBSD developer has tested my code and has seen > >a significant performance improvement over their old code, and are > >evaluating if they want to/can include it in their tree... > > > >Hope this answers your question. If not, please be more specific so > >I can answer it. > > I'm sorry, I thought that is the paper that is a transcript of the > following presentation: > > http://2013.diac.cr.yp.to/slides/gueron.pdf > > made by the same authors. The transcript is not available so far it seems. > > And regarding assembler/C maintainability I would argue that the current > intrinsics based implementation is more readable than the pure assembler > solution (and it is still machine dependent). Of course, I'm not the > expert in such optimizations, so that is just my own feeling. > > By the way, do you have some concrete numbers about the performance of > your aes-gcm? (I recently could do aes-128-gcm at about 32 gigabits/sec > that is not a limit of the modern hardware for sure). So, in bare metal userland testing, iirc, I was able to get around 1GByte/sec on a single core... That doesn't take into account kernel and framework overhead... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."