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 [EMAIL PROTECTED]
