From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 19:02:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E05F16A4CE for ; Tue, 1 Mar 2005 19:02:14 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16CC443D1F for ; Tue, 1 Mar 2005 19:02:14 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 415CF37017; Tue, 1 Mar 2005 14:01:56 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Mon, 28 Feb 2005 14:02:01 PST." <200502282202.j1SM21qs042751@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 14:01:56 -0500 From: Roland Dowdeswell Message-Id: <20050301190156.415CF37017@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 19:02:14 -0000 On 1109628121 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >Yes, the data sector is written first and then the key sector. >Since, as you pointed out, GBDE is more susceptible to dictionary >attacks than CGD one can then use this advantage (it's a feature, >not a design flaw!) to recover the lost key so no data is lost. :-> > >Seriously, how can one make writing atomic without breaking >compatibility with existing GBDE volumes? Which approach does CGD >use to solve the problem of atomic writing? You would need to maintain some sort of journal. With CGD, I specifically avoided any strategy which tied the write of one sector to the write of another sector for this reason. And so, I use one key to encrypt the disk rather than storing randomly generated keys upon every write. GBDE already explodes a single sector write into two sector writes, which makes its performance quite suboptimal. Adding a journal would make it even worse. I do not think that maintaining a different key for each sector actually provides enough benefit to justify this. >How about changing GBDE in a backwards-incompatible way by adding >one key shadow sector for every n key sectors (n would be chosen at >volume initialization)? The key shadow sector would hold the xor of This is basically implementing a journal. It adds a lot of complexity for IMO very little gain over moving to a simpler solution such as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard to change without breaking. This would make it more so. And, GBDE is obviously already less secure than a simpler approach such as CGD with AES-256 (which is around twice as fast). Many rather dubious claims have been made about GBDE such as in: http://www.bsdcan.org/2004/papers/gbde.pdf PHK claims that it will take O(2^384) to crack GBDE if the lock sector is destroyed. Perhaps my maths is a little rusty, but it perplexes me how it could possibly take 2^384 steps to individually crack 2^30 sectors that are encrypted with 128 bit AES. That comes out to a [not at all strict] upper bound of 2^158 steps to entirely crack a 512GB disk. So, already it is less secure than CGD using 256 bit AES. But, obviously you'd just crack the ``key-key sectors'' which would knock another 5 bits off. Now, consider that really an attacker doesn't really care about the whole disk. By chasing directory structures, etc., they could find what they wanted in very little more than O(2^128). So, what's the point of all of the gymnastics... a few bits. It is also structured in such a way that substantial breakthroughs in the cracking of many different encryption algorithms, hashes and random number generators will bring the house of cards down. I do not believe that it has had an appropriate amount of peer review to be considered trustworthy, and I have seen some pretty obvious weaknesses that I've been meaning to write up but haven't quite found the time that would knock a few more bits off. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/