[17023] in cryptography@c2.net mail archive
Re: comments wanted on gbde
daemon@ATHENA.MIT.EDU (Joseph Ashwood)
Sun Mar 6 14:44:55 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "Joseph Ashwood" <ashwood@msn.com>
To: <cryptography@metzdowd.com>
Date: Sat, 5 Mar 2005 21:40:37 -0800
----- Original Message -----
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
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
cryptography.
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.
Joe
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
