In message <20050303214150.GA28836@panix.com>, Thor Lancelot Simon writes:
>On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote:
>> 
>> And if CGD is _so_ officially approved as you say, then I can not
>> for the life of me understand how it can use the same key to generate
>> the IV and perform the encryption.  At the very least two different
>> keys should have been used at the "expense" of making the masterkey
>> 512 bits instead of 256.
>
>Why "should" two different keys have been used?  It is possible that I
>misunderstand the underlying theory, but so far as I do understand it
>the only real requirement for IVs is that the Hamming distance between
>any two used with the same encryption key be large.

On this point, I tend to agree with phk -- it's generally a bad idea to 
use the same key in two different contexts, because there can be 
interactions.  I'd be happier if a different mechanism were used to 
generate the IV, such as HMAC of the key and block number, or 
encryption of the block number with a hash of the key, or by stretching 
the input key to a longer output key per PKCS#5 and using the two 
halves for different purposes.  While I don't see a real attack to 
worry about here, in some situations there's a possibility of a chosen 
plaintext attack:  I write 0s to block #k; the ciphertext of the first 
16 bytes of that block will be encryption of k under the same key.  I 
hasten to add that that's *not* even close to a real attack for lots of 
reasons, not the least of which is that AES was designed to resist 
chosen plaintext attacks in far more devastating circumstances.

The other change I think is important for cgd is to provide a 
key-changing mechanism.  That is, I'd like to have a key from
/dev/random or /dev/urandom used for the actual encryption, but have 
that key encrypted via the PKCS#5-converted password.  That's a small 
change to cdgconfig; another change would be needed to provide the 
password-changing code.  Again, phk is right about this point, though 
his paper misstates the reason: it's not that "all security policies
we have ever seen, contain a rule which says 'passwords must be
changed every N {days,weeks,months}'. This is sound thinking, and
GBDE should support it." -- such policies tend to be rather stupid,
in fact.  Rather, it's addressing the crucial weakness of any of these
schemes: users pick bad passwords.

A more interesting, and to me open, question is whether or not
one needs to worry about encrypting too much data with one key.
AES in CBC mode does have a limit of 2^64 blocks, or 2^68 bytes.
If we assume you can buy a 1 TB (i.e., 2^40 byte) disk today, and
we assume that disk capacity is doubling every year, we'll hit that
limit in 28 years.  Of course, assuming that doubling will continue for
28 years is a stretch, but one can always use RAID to build bigger
file systems.  The real question, though, is whether or not there's
a limit significantly smaller than 2^64 blocks.  Note, too, that such
a development doesn't affect the security of data written to today's
smaller disks.

But this discussion has degenerated into name-calling.  I suggest that
a pointer to the gbde paper be posted to the cryptography mailing
list.  Yes, Perry is the moderator; no, that's not a problem even
for those he disagrees with.  He does a clean, fair job.  Besides, that
list is one place where members of the Cryptographers' Guild do interact
with "real programmers" -- the list has quite a collection of each,
plus some people who live in both worlds.  That latter category
includes me (I don't design cipher algorithms; I do design -- and
attack -- cryptographic protocols), David Wagner, Hugo Krawczyk (one of
the inventors of HMAC), and many others.  

You can subscribe to that list by sending to cryptography@metzdowd.com.