Date: Thu, 03 Mar 2005 21:13:58 -0500 From: "Steven M. Bellovin" <smb@cs.columbia.edu> To: tls@rek.tjls.com Cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE Message-ID: <20050304021358.206813BFE3B@berkshire.machshav.com> In-Reply-To: Your message of "Thu, 03 Mar 2005 16:41:50 EST." <20050303214150.GA28836@panix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050304021358.206813BFE3B>