From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 02:14:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3879C16A4CE for ; Fri, 4 Mar 2005 02:14:03 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B927543D41 for ; Fri, 4 Mar 2005 02:14:02 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 4B863FB28F; Thu, 3 Mar 2005 21:14:02 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2C24FB285; Thu, 3 Mar 2005 21:14:00 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 206813BFE3B; Thu, 3 Mar 2005 21:13:58 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: netbsd From: "Steven M. Bellovin" To: tls@rek.tjls.com In-Reply-To: Your message of "Thu, 03 Mar 2005 16:41:50 EST." <20050303214150.GA28836@panix.com> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 03 Mar 2005 21:13:58 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050304021358.206813BFE3B@berkshire.machshav.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 02:14:03 -0000 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.