Date: Tue, 06 Jun 2006 15:30:42 +0200 From: Christian Brueffer <brueffer@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sbin/geom/class/eli geom_eli.c Message-ID: <20060606133042.GA2370@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20060606070827.GC72060@garage.freebsd.pl> References: <20060605223446.AD29316DBF5@hub.freebsd.org> <4484DB40.1010907@root.org> <20060606070827.GC72060@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060606133042.GA2370>