Date: Mon, 28 Feb 2005 02:15:15 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Roland Dowdeswell <elric@imrryr.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <42226293.7040603@FreeBSD.org> In-Reply-To: <20050227213032.CCB973700F@arioch.imrryr.org> References: <20050227213032.CCB973700F@arioch.imrryr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Roland Dowdeswell wrote: > [ cc'ing tech-security@NetBSD.org, 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@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. Well, I think that this is quite minor item, since GBDE doesn't govern transformation of the passphrase into the actual key, so that another scheme more bullet-prof against dictionary attacks (PKCS#5 or any other) can be developed in virtually no time at all and will require making only minor changes to the userland utility which gets password from the keyboard or command line, hashes it and feeds to the kernel. > 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). Well, it's hard to comment on this, since the only paper that I have found on CGD is http://www.imrryr.org/~elric/cgd/cgd.pdf, which unfortunately doesn't provide any details on how CGD encrypts data and lays it out on disk. > 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. So what? If the write fails in the middle, reading sector will just produce garbage. I don't think that it's different from plain old HDD which has been powered down in the middle of doing disk write. Disk encryption layer is definitely not the level at which journaling should be implemented. It's task of file system to do this. The task of encryption layer is merely to inform the file system when transaction (i.e. both of those two writes in this case) have been completed successfully, so that FS can adjust its journal accordingly. -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42226293.7040603>