RFC: backporting GEOM to the 4.x branch

ALeine aleine at austrosearch.net
Sun Feb 27 15:00:55 PST 2005


elric at xxxxxxxxxx wrote: 

> [ cc'ing tech-security at xxxxxxxxxx, because there has been talk
>   of GBDE there in the past.]
> 
> Well, I thought that since I saw this:
> 
> ALeine wrote a while ago:
> >df at xxxxxx wrote:
> >>
> >> Wouldn't be easier porting cgd* from NetBSD ?
> >>
> >> * http://www.netbsd.org/guide/en/chap-cgd.html
> >
> >Perhaps, but I believe GBDE to be superior to CGD for a number
> >of reasons, one of the most important being that with GBDE you
> >can change the passphrase without re-encrypting the entire disk,
> >which is not the case with CGD, AFAIK. From Poul-Henning Kamp's
> >paper on GBDE:
> 
> That, as the author of CGD, I should respond to some common
> misconceptions about my work which seem to be percolating around.
> 
> First, on the capability front, you can:
> 
> 1.  change the passphrase on a disk without re-encrypting it,
> 2.  have as many passphrases as you would like to configure,
> 3.  use n-factor authentication with arbitrary large n.
> 
> Also, GBDE has a number of serious drawbacks.  All of which would
> be show-stoppers if I were considering using it for serious security
> work, or even use in a production environment.
> 
> There is no protection _at_all_ against dictionary attacks.  Where
> CGD uses PKCS#5 in a completely standard way to frustrate dictionary
> attacks, GBDE does exactly nothing.  In fact, worse than nothing.
> It is possible to conduct half of the dictionary attack offline,
> so the actual online portion of the attack is something that my
> laptop could make about 2^30 guesses in a couple of hours.  So, it
> is insecure from the start.
> 
> GBDE has no facility for using different encryption algorithms than
> the rather...  interesting one that it comes with.  There is no
> way to trade speed and security for different use cases, and the
> only algorithm that it comes with is very slow.  Less than half
> the performance of CGD's most secure algorithm (AES256).
> 
> So, now that we've touched on the security problems...  Let's think
> about using GBDE in production.  Please reference
> 
> http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> 
> And read Section 7.5, and refer to figure 2.
> 
> Each disk write involves two writes to the disk.  Where is the
> journal?  I do not see any talk about a journal in the paper, or
> the GBDE source code.  Hence, if the OS crashes or if a removable
> disk is removed at the wrong time, etc. etc. it is possible that
> only one of those writes would succeed.  I think that we can all
> see where this is going.
> 
> --
>     Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

Thank you for taking the time to write that very informative post.
I was not fully aware of all the issues you raised here, I'll look
into them. In the meantime maybe someone more familiar with GBDE
than myself could share their comments. I am CC:-ing this to
freebsd-hackers at xxxxxxxxxxx as well since I originally posted
there as well.

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net 





More information about the Kernel mailing list