From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 18:46:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D7E10656A4; Tue, 7 Sep 2010 18:46:26 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9038FC17; Tue, 7 Sep 2010 18:46:25 +0000 (UTC) Received: by ewy4 with SMTP id 4so2902849ewy.13 for ; Tue, 07 Sep 2010 11:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=k6WNfQ5ZWZzsWdzYWeiMBMoiJIBNFCZLUknp3lKaOtU=; b=hM+eXpUyyM+YiUvdwOars14au+Krr3FnO+nGxTtY0d6fFyz1MtwiKzNJTmSTu80zhg PgU8s/2f1D+HbFtErbUF+lmn6E/+eKtZ5KgCLdgbbFEGKmByNxg7F6yjBgtw6Hxsp9Vt fz6JxN/NVzcoSvkXTfoR1ja/gyFF0QXq1Okco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JYINIZqDL7a0Hlxda5nD2ZnpOyZrl15diGhYomDbYheMc2sfpOo+3DoykFmYuRL6cW GQQUAzEMNevXTe07rtqWIR1/oG8AwVKvO6AeEjJitruOy6dhliBQReGeHSZUbGgpS8qT URIQylah+uFIIE2SWQVXBB38thQ9Fy53Jxppo= Received: by 10.213.47.70 with SMTP id m6mr112986ebf.63.1283885184286; Tue, 07 Sep 2010 11:46:24 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v59sm10370105eeh.4.2010.09.07.11.46.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:46:23 -0700 (PDT) Date: Tue, 7 Sep 2010 21:46:18 +0300 From: Gleb Kurtsou To: Kevin Oberman Message-ID: <20100907184618.GA2611@tops> References: <20100907175738.889611CC3A@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100907175738.889611CC3A@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, Robert Watson Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2010 18:46:26 -0000 On (07/09/2010 10:57), Kevin Oberman wrote: > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > since then. I've recently added support for sparse files and switched to XTS > > encryption mode. > > > > I've been using it to encrypt my home directory for almost a year already, > > and use fsx, dbench and blogbench for testing. So it should be fairly > > stable. > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > 8-STABLE supported. > > > > Please email me separately if you're willing to help testing on big endian > > machine, XTS code doesn't look endian correct. > > > > At this point all of the project goals complete and I'd like it to get wider > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > soon. > > I've got to ask a probably dumb question...how is this better then geli > encrypted objects? I've used them for sometime with excellent results. > > Or does it provide functionality that geli does not? If geli works for you I'd suggest you continue using geli, geli design is order of magnitude simpler due to being block device but not a filesystem. Besides geli provides data authentication, which is very important, and something that can't be easily implemented in stacked filesystem. Pros of stacked filesystem approach: * You don't have to create separate filesystem (use separate partition), just encrypt part of existing filesystem * It's easier to create/manage snapshots/backups (imho) * Ability to use multiple keys, each directory can have its own key, files with different keys can be mixed in one directory, etc. You don't have to create another filesystem and claim that you don't know password for this one if you're asked to provide it, in case you have something to hide ;) Cons: * pefs maximum file name length is ~180 bytes, but not 255 * Stacked filesystem is likely to be slower due to extra overhead I don't really know what makes one better then other, it has only on thing in common - encryption - everything else is different. It depends on how you intend to use it. I was using geli myself, the only problem I had was that at some point I realized that initial partition size was too small :) But that more or less applies to both approaches. E.g. non-standard example where stacked filesystem may be preferred is to use it for encrypted crash dumps: if dump available on dumpdev mount /var/crash as pefs; ask user for password, or automatically add random one and let user to save it later after boot. Crash dumps are encrypted without extra cost of setting up partition, geli, etc. Thanks, Gleb. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751