From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 23:47:05 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 339C567D; Mon, 7 Oct 2013 23:47:05 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9D3A2E88; Mon, 7 Oct 2013 23:47:04 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so3182493qeb.3 for ; Mon, 07 Oct 2013 16:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OzZJcuN9nNcKm2izc1a8vcQpgKgBWtUfHpVY4nls1Iw=; b=fq5/mJrqQMitF44dvVQ13veVBG8ZlSSKiglMHB0BVqPHtxe7mxtqwwhmZcNKuSruXA /mWGHDaDuQAYfmktZwcGah1Pc97CgPLpI1zNUALFo9EFPUTen+/0rEb25z4UR/H4JGux MuELCBV/jS4vkA1dHVfZaRvsGxi4KF72zV2G/OVya6TpcOicUi2fZlPSYt1wBSnooZ4y 99iDggGlCXhyXm010R6Bwn2b+u9GJWMtA2OzFoAKgOPqRs7OE9k4wKA56veq7fyCsay2 4WzwbG+LA1el5oG8nQNw8B753+GtYgg6mIVFpeK4ftNnMBP0He3O6RhcvV4dbM1U9i+c 38iQ== MIME-Version: 1.0 X-Received: by 10.224.60.199 with SMTP id q7mr178408qah.80.1381189624051; Mon, 07 Oct 2013 16:47:04 -0700 (PDT) Received: by 10.229.114.5 with HTTP; Mon, 7 Oct 2013 16:47:03 -0700 (PDT) In-Reply-To: <20131007231734.GY56872@funkthat.com> References: <20131007163111.GB1590@reks.swifttest.com> <20131007231734.GY56872@funkthat.com> Date: Mon, 7 Oct 2013 16:47:03 -0700 Message-ID: Subject: Re: Committing PEFS to CURRENT From: Gleb Kurtsou To: Gleb Kurtsou , freebsd-current@freebsd.org, "delphij@freebsd.org" , Kris Moore Content-Type: text/plain; charset=UTF-8 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: Mon, 07 Oct 2013 23:47:05 -0000 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 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. > 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. > 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. > 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."