cvs commit: src/sbin/geom/class/eli geom_eli.c

[Christian Brueffer]

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
> +> 
> +> Excellent!  One of my longstanding complaints has been that no block encryption software supported integrity, only privacy.
> +> 
> +> http://www.root.org/talks/Usenix_20040629.pdf
> 
> 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...)
> 
> +> As far as the flag change goes, won't this make it difficult to MFC this new feature later?
> 
> 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.
> 
> If needed I can eventually accept encryption algorithm specified with
> '-a' flag and print a warning.
> 

From 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

-- 
Christian Brueffer	chris at unixpages.org	brueffer at FreeBSD.org
GPG Key:	 http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060606/b6682d09/attachment.pgp