From owner-freebsd-current@FreeBSD.ORG Tue Oct 8 00:23:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2173366E; Tue, 8 Oct 2013 00:23:16 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E943D20E2; Tue, 8 Oct 2013 00:23:15 +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 r980NEUu091684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Oct 2013 17:23:15 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r980NExM091683; Mon, 7 Oct 2013 17:23:14 -0700 (PDT) (envelope-from jmg) Date: Mon, 7 Oct 2013 17:23:14 -0700 From: John-Mark Gurney To: Gleb Kurtsou Subject: Re: Committing PEFS to CURRENT Message-ID: <20131008002314.GA56872@funkthat.com> Mail-Followup-To: Gleb Kurtsou , Gleb Kurtsou , freebsd-current@freebsd.org, "delphij@freebsd.org" , Kris Moore References: <20131007163111.GB1590@reks.swifttest.com> <20131007231734.GY56872@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-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]); Mon, 07 Oct 2013 17:23:15 -0700 (PDT) Cc: Gleb Kurtsou , freebsd-current@freebsd.org, "delphij@freebsd.org" , Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 00:23:16 -0000 Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 16:47 -0700: > On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney wrote: > > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: > >> Patch is available here: > >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > > > > Is there a reason you are writing your own AES-NI implementation instead > > of using the OpenCrypto framework? > > It reuses the same AES-NI implementation used by opencrypto, > but code doesn't use opencrypto directly. Main limitation in opencrypto is > that is incomplete implementation AES-XTS -- it doesn't implement ciphertext > stealing. opencrypto contexts seemed to be too much overhead list time I I remember noticing that when I was working on it.. but as there are different modes of packing/padding, I decided not to do anything with that... I also don't like your lack of comments arround xts_lastblock and about why it is accessing dst - 1... To me, you should pass in the previous block as an arg to xts_lastblock instead of doing dst[-1]... You did comment what you're doing (m - 1), but not why it is safe to do that... There is no comment that you're implementing ciphertext stealing w/ the function which makes it even harder to understand that you'd going it properly... It wouldn't be hard to add ciphertext stealing to the opencrypto implementation if that is really all that is missing... but.. > looked at them especially in the case of multiple keys per file system in PEFS. > AES-NI interface is not designed to be used outside of opencrypto thus > some minor copy-past. We have discovered that by the "minor" copy/paste we now have an inferior implementation of AES-XTS... If it performed similar to the one before it, it is over 10x slower than the one that I committed.. > > I updated the kernel's AES-NI implementation to have a very fast > > AES-XTS... Upon looking at your implementation, you have a very > > slow implementation as you do not pipeline AES-XTS at all... Please > > switch to using the opencrypto version.. You'll then be able to make > > use of any accelerators that other platforms may have... > > I was looking into incorporating AES_XTS pipeline changes in PEFS. > I'd like to avoid switching to opencrypto at this point. But pipelining is > doable without opencrypto and copying code around. I really don't like the idea of adding yet anothe AES-XTS implementation to our tree (especially considering how bad both the previous one and this one is)... Even if you do bring over the pipeline changes... It'll be yet another copy of code to maintain and port performance improvements too... We could always refactor the AES-NI code to make it more usable outside the opencrypto framework as a stepping stone to possibly using pjd's improved opencrypto framework... But copy/pasting just because we don't want to do a bit more work isn't good justification... > > Are there plans to add authentication to this scheme? See that as a > > todo, but w/o authentication, you can't store anything reliably on it.. > > And w/ XTS, the attacker can take pot shots at your file in 16 byte > > chuncks... > > I have data authentication prototype. It's too far from being complete, > and I keep working on it as time permits. There are a few more ideas > I'd like to work on while redesigning the file system. > > Patch also includes hmac and pkcs5v2 implementations which in fact > were generic versions to go under sys/crypto until yesterday. > Considering we are late in code freeze already I've merged them > into PEFS not to touch geli code with the patch. Can't you keep them named the same under sys/crypto and just link w/ them as necessary to prevent repo churn when you finally integrate them into sys/crypto? That seems better than moving them arround, though I guess w/ svn, it isn't as big of a deal... Someone w/ a repo hat on should chime in here... > > The only reason I'm running zfs on geli w/o authentication is that I'm > > using a 256bit checksum, so the chances of someone modifing two blocks > > to fool zfs into decrypting the correct new checksum value for their > > modified block is very small... In short, I'm trusting zfs to do the > > authentication for me... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."