DragonFly kernel List (threaded) for 2005-03
Re: RFC: backporting GEOM to the 4.x branch
On 1109628121 seconds since the Beginning of the UNIX epoch
>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
>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:
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/