Talk:GBDE

From Wikipedia, the free encyclopedia

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

[edit] Master key size

I think stating the size as 2048 bits is inaccurate. It consists of a 128 bit salt and a 2048 bit lookup table, which means the key size is 2176 bits in total. (At most 256 bits of that is used for generating each sector key). Kasperd 11:30, 3 January 2007 (UTC)

Yes, good point. I think you're confusing "sector key" with "key-key", though; see my post below. -- intgr 13:20, 3 January 2007 (UTC)

[edit] PRNG weakness

I don't believe the statement "However, as long as the operating system's PRNG for the master and sector keys is secure, this does not compromise the system." is true. The quality of the random bits in the master key is not the issue here. A different PRNG is used to generate the sector keys from the master key, and this is the one which is not proven secure. Kasperd 11:30, 3 January 2007 (UTC)

As far as I understood the design paper, the master key as well as the sector keys are generated with the operating system's CSPRNG; only the keys that the sector keys are encrypted with (called "key-keys"), are generated with the cherry picker. GBDE would seem secure [to me] even if all the sector keys were encrypted with a single constant key-key.

Quoting the paper, "A new sector key is generated with the standard (P)RNG facilities in the kernel and the sector data encrypted using AES/CBC/128. The sector key is encrypted with AES/CBC/128 using the key-key and inserted at the correct place in the key sector."

I wouldn't even call the cherry picker a PRNG — it's designed to be deterministic, that is, to derive the same key for a given sector number every time. It merely picks bytes from the master key, concatenates them with the sector number and hashes with MD5. "Key derivation algorithm" would sound more appropriate. -- intgr 13:20, 3 January 2007 (UTC)

A PRNG takes a small amount of random input and generates a larger amount of random output. In case og GBDE a 2176 bit input is expanded into 128 bits of random output per sector on the device, thus for any device with 18 sectors or more the algorithm satisfies this definition of a PRNG. Except the output it produces is not uniformly distributed. In fact even if you just take a single of the generated 128 bit keys, it will have a nonuniform distribution. This is why I don't believe in the claims about the security. I agree that if you removed this 2176 bit master key and the cherry picker and replaced it all by a static 128 bit key, it would probably be secure. Kasperd 22:57, 4 January 2007 (UTC)

If even one static key would do, then does the PRNG in this situation need to be uniformly distributed? Seems to me that as long as the attacker cannot guess it, it is secure. Since it's mainly derived from the master key, which is random, I cannot see how the attacker would predict it. -- intgr 03:04, 5 January 2007 (UTC)

When it is not uniformly distributed, an attacker can do a brute force attack starting with the most likely keys and ending with the least likely. On average you will find the correct key faster than you would in case of uniformly random keys. Also on a large media you can be almost certain there will be at least one sector with a weak key. And if the attacker manages to find the key used for one single sector, he will also know part of the master key, which makes it easier to brute force remaining sectors. The weak point is the value you have after using the lookup table just before the second use of MD5. The 16 bytes you get will have a tendency to contain many identical bytes. Thus an attacker will start trying keys with all bytes being identical, next try keys which contains only two different byte values. Kasperd 19:20, 5 January 2007 (UTC)

True. Thanks for taking the time to explain. :) -- intgr 19:57, 5 January 2007 (UTC)