From owner-cvs-src@FreeBSD.ORG Tue Jun 6 13:30:50 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A4D316ABA2; Tue, 6 Jun 2006 13:30:50 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 737AB43D45; Tue, 6 Jun 2006 13:30:49 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0F00K7IXJ718@ms-dienst.rz.rwth-aachen.de>; Tue, 06 Jun 2006 15:30:44 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Tue, 06 Jun 2006 15:30:42 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k56DUgVA024132; Tue, 06 Jun 2006 15:30:42 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fnbdq-0001pe-Ln; Tue, 06 Jun 2006 15:30:42 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 5B61E3F431; Tue, 06 Jun 2006 15:30:42 +0200 (CEST) Date: Tue, 06 Jun 2006 15:30:42 +0200 From: Christian Brueffer In-reply-to: <20060606070827.GC72060@garage.freebsd.pl> To: Pawel Jakub Dawidek Message-id: <20060606133042.GA2370@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary="W/nzBZO5zC0uMSeA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.1-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20060605223446.AD29316DBF5@hub.freebsd.org> <4484DB40.1010907@root.org> <20060606070827.GC72060@garage.freebsd.pl> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Nate Lawson Subject: Re: cvs commit: src/sbin/geom/class/eli geom_eli.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 13:31:00 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 06, 2006 at 09:08:27AM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jun 05, 2006 at 06:32:48PM -0700, Nate Lawson wrote: > +> Pawel Jakub Dawidek wrote: > +> >pjd 2006-06-05 21:40:54 UTC > +> > FreeBSD src repository > +> > Modified files: > +> > sbin/geom/class/eli geom_eli.c Log: > +> > Userland bits of geli(8) data authentication. > +> > Now, encryption algorithm is given using '-e' option, not '-a'. > +> > The '-a' option is now used to specify authentication algorithm. > +> > Supported by: Wheel Sp. z o.o. (http://www.wheel.pl) > +> > Revision Changes Path > +> > 1.11 +29 -15 src/sbin/geom/class/eli/geom_eli.c > +>=20 > +> Excellent! One of my longstanding complaints has been that no block e= ncryption software supported integrity, only privacy. > +>=20 > +> http://www.root.org/talks/Usenix_20040629.pdf >=20 > The problem is that it was not easy to make it reliable, ie. to be sure > that storing both data and HMAC is atomic operation, so user won't get > false postitives on system crash or power failure. > But I found a way to do it, so here it is:) > If you are interested how it is done, I tried to describe it at the > beginning of g_eli_integrity.c. > (I need to write a paper about GELI someday...) >=20 > +> As far as the flag change goes, won't this make it difficult to MFC th= is new feature later? >=20 > One will get an error if it tries to specify encryption algorithm with > '-a' flag, so nothing bad will happen. > I handle metadata backward compatibility, so we are safe here. >=20 > If needed I can eventually accept encryption algorithm specified with > '-a' flag and print a warning. >=20 =46rom a documentation point of view, that solution would be best. In the handbook we could simply say "from 6.2-RELEASE on use -e to specify the crypto algorithm" and not leave RELENG_6 users from the MFC date to the day of the release in the dust. BTW, great stuff! - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEhYOCbHYXjKDtmC0RAnzoAJ9UeFEzOt+7yuZww6oDa21FhFJHBwCfXE/v /h6W0guHIdFJesXM5jZkGok= =OOHH -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--