comments wanted on gbde

Joseph Ashwood ashwood at
Sun Mar 6 00:40:37 EST 2005

----- Original Message ----- 
From: "Steven M. Bellovin" <smb at>
Subject: comments wanted on gbde

I'll just deal with it piece by piece.

Page 3 "decrypting and re-encrypting an entire disk would likely take more 
than a day with currently available hardware" is wrong. Assuming 256-bit 
AES, using a two-pass encryption system, on a 2.1 GHz pentium 4 (currently 
below low end) this would equal a disk of over 1000GB (numbers taken from 
Crypto++ benchmarks), personally I don't have a laptop with that kind of 
space. I have a rackmount server with that space, and my desktop is getting 
close, but no where near full. Even by page 3 I'm becoming doubtful about 
the abilities and there isn't any real information yet.

Page 3 again, system supports multiple access paths. Clearly this means that 
either the entire disk, or per block or per sector or whatever has an 
encrypted key, this is how they will meet the false criteria above, and the 
multiple access path. Of course this is a standard technique, and has been 
around for ages, nothing new here.

Page 4 "It has been said that there is only one really hard problem in 
cryptography: the problem of key management. GBDE does not try to address 
that." They're already admitting to heavy flaws, downplaying the abilities 
of the design, not a good sign.

Page 5 finally begins the actual information.
Page 5 "plaintext sector data should be encrypted with one-time-use 
(pseudo-)random keys" serves no purpose if a strong mode is used.  The only 
purpose this serves is to slow the system down as additional searches have 
to be made. This is claimed to provide protection from when AES is broken. 
It offers nothing except wasted cryptographic and disk overhead.

Page 5 "RSA2/512 as strong one way hash" just in case I was wrong and this 
does exist, I ran a quick google for it, and found the only references to it 
are in reference to this paper. I suppose they meant SHA-512, which further 
brings the question: Why are they using a hash function at all? Obviously 
this is where the decrypt/encrypt taking more than a day came from, SHA-512 
is slow, using 256-bit AES in a properly secure mode using a MAC would have 
been better cryptographically, better for storage, computationally easier, 
and would have substantially reduced the window of exposure (A break of 
AES-256 would have been required instead of a break of either AES-128 or 
SHA-512). Further the choice of MD5 as a "bit blender" is extremely 
questionable, and again it would have created a much smaller window of 
exposure to use an AES CBC-MAC with a known key and IV. Obviously this was 
not built by someone with anything more than a rudimentary knowledge of 

Still on page 5, (apparently unkeyed) MD5 is used as a MAC of the lock 
sector. Very, very poor security decision.

Using variable formatting. How many times do we have to kill this before it 
stays dead? Obviously more, probably many more. Variable formatting gains 
you nothing, consumes entropy, and consumes cpu time, it also often is the 
foundation for the break.

Page 6 covers the paranoia plausible deniability. Strangely although they 
seem to imply that the current GBDE does this they apparently have chosen 
not to even begin covering this, so most likely they either make no real 
attempt at it, it doesn't work, or both.

Page 6, section 7.4 covers using MD5 to make sure the performance is as bad 
as possible by maing it impossible to precompute where data will be.

The footnote on page 6 should read "In both cases the encoded sector address 
was placed in the middle to ensure the worst possible performance, 
cryptographically it makes no difference"

In the Known Weaknesses section they forget something important THERE IS NO 
MAC ON THE DATA. This means that there is no possibility of detecting an 
attack, not possibility of determining what has been tampered with. In short 
the real level of security fails miserably.

Section 16 likes to hint that David Wagner and Lucky Green peer reviewed 
this paper. Assuming this is true, my best guess is that the authors mistook 
a statement of "This should be secure" for a statement of "This is good" 
that is unless there are enormous holes in the paper.

GBDE is built on concepts that are nonsensically put together, the design 
itself is out of date by at least a decade, and makes a wide number of 
extremely amateur decisions.

The most important point to make is that this paper shows rather well that 
while developing something "secure" is difficult, something that is "good 
and secure" is substantially more difficult.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list