From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 20:28:18 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 DF7F410656B5; Tue, 7 Sep 2010 20:28:17 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1A08FC1E; Tue, 7 Sep 2010 20:28:16 +0000 (UTC) Received: by eyx24 with SMTP id 24so2978521eyx.13 for ; Tue, 07 Sep 2010 13:28:16 -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=3TRteP0OxHiUHJxJhjySDVZ0wxp0EJ2oATtM42RegwA=; b=A34iVJcWNN5TrN5rb/QWpBqmoLWg0Bp1iRmU9RA7e/Ur+147w/498F+/2bZAuzV2Mr rM4KYIj4wQdLIKQx6GFregVWp+Y5vz5ciawtF7LdDaR0rG7GB6PPOg6WXLrfEvcDEFQ2 sa6cIcGwaU6YyOWWeCUT+DyEfCEkBHoayf7vQ= 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=DOthkPRqMCxcTHhM6StRy0hI5x8McKHmqbQZjHf+t/9kYreA5iqTReN5/g7KGGqCMv OK6m5ltfn64uwAsSuc8wxc9dsAc59ws1n2lF7f6LJyUb2sijVXie4lhDxbbYofdI2/Rx Sx2FvynoPYnDIIbAkm+bQo+zW8C+F1Knsn960= Received: by 10.213.45.194 with SMTP id g2mr36579ebf.0.1283889913302; Tue, 07 Sep 2010 13:05:13 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id u9sm10487472eeh.11.2010.09.07.13.05.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 13:05:12 -0700 (PDT) Date: Tue, 7 Sep 2010 23:05:07 +0300 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20100907200507.GB2804@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org 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 20:28:18 -0000 On (07/09/2010 16:27), Ivan Voras wrote: > On 09/06/10 20:38, Gleb Kurtsou wrote: > > Hello, > > > > 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 tried it and so far it works :) > > > 3. Mount pefs filesystem: > > # pefs mount ~/Private ~/Private > > I see you've used the same example in the man page. Maybe it would be > better for educational purposes to use two separate directories, e.g. > ~/Private and ~/Decrypted to avoid confusion by new users (of course not > all examples need to use this). Actually I've used the same directory solely for educational purposes -- there is just one directory, it's either encrypted or not. Users should think of it as of nullfs on steroids, but that doesn't sound acceptable for man page. Seriously, any help on documentation is more than welcome. I'm not good at writing it, and there is too much to document. We could discuss all the details privately to write a decent man page, if you have time to help. > > 6. Example how to save your key in keychain database. > > This is probably in line with what rwatson said (and would be covered by > the same document): can you describe what keychains actually do? Yes. I was thinking about 6 and 7 as of feature list, so no documentation or instructions. Keychains are mentioned in man page, but once again documentation is far from being good. Help wanted. Most important fact is that keychains have nothing to do with filesystem, it's solely userspace utility concept. Chain is a series of keys (keychain db entries). Each db entry consists of two keys: parent key and child key. Child key may be zero, i.e. end of chain marker, (created by addchain -Z). Keychain database itself is a dictionary of the following form: db[parent_key] = child_key Consider the following database: db[k0] = 0 (zero child key) db[k1] = k2 db[k2] = k3 db[k3] = 0 k0 is special. Its child key is zero (end of chain). Chain would consist only of one key: k0 If user enters k1, the following chain can be retrieved from the database: k1 k2 k3. All three keys are then added to filesystem. In case of k2 chain is k2 k3. All entries stored encrypted in a way that child entry can be decrypted only by parent key. Using key chains one can emulate access levels. (Don't miss 'pefs randomchain' command which was invented especially to make some fun for those trying to look at your data) > > 7. You can setup pam_pefs (not compiled by default) to add key to home > > directory and authenticate against keychain database on login, e.g. by > > adding the following line to /etc/pam.d/system before pam_unix.so: > > > > auth sufficient pam_pefs.so try_first_pass > > So, this would bypass passwd and let the user in if his password > authenticates against the "keychain database" in his home directory? Exactly, that's the way I use it. More detailed description available here: http://marc.info/?l=freebsd-current&m=128388197901390&w=2 > Will it automagically pefs-mount his home directory? No, not mounting pefs is intentional. It automagically adds keys to already mounted pefs filesystem. > > > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > > PKCS#5v2 and HKDF for key generation. > > I do have an request: since you are already using kernel crypto support, > it would be simple to just throw Blowfish in :) If for nothing else, > consider it a gift to those who are fond of Blowfish's large key sizes > (upto 448 bits). XTS requires 128 bit block cipher. One can use Blowfish to encrypt two 64 bit subblocks, but one would need to mix these blocks somehow, that what XTS does :) A bit tricky to implement. Adding serpent or twofish should be easy. > Actually, it would probably be seen as a reflection of consistency to > implement the same algorithms that geli(8) implements. geli doesn't > implement XTS yet - if your XTS code proves to be stable it would be a > good thing to include it as standard and then use it from geli. The problem is 128 bit block in XTS, in my opinion hacking XTS to add support for algorithms with other block sizes is a very bad idea. There are more than enough modern algorithms that can be used instead. Not sure how far "reflection of consistency" extends but pefs is very likely not to support modes other then XTS, because for now it's the only widespread standard mode of operation with arbitrary sector size and arbitrary offset encryption. > I see you've copied SHA2 code to the pefs code. What is wrong with just > using the kernel's SHA2 implementation? That was accidental, or there was a reason I've already forgotten about. Anyway it's just a copy from kernel, my intention was to make it easier to test by users. There's hmac which is one-to-one copy from geli. I've extracted it because now both geli and pefs use same code. Thanks, Gleb. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"