Date: Tue, 01 Mar 2005 17:15:11 -0500 From: "Steven M. Bellovin" <smb@cs.columbia.edu> To: "ALeine" <aleine@austrosearch.net> Cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <20050301221511.3423C3C023E@berkshire.machshav.com> In-Reply-To: Your message of "Mon, 28 Feb 2005 17:45:15 PST." <200503010145.j211jF1s046188@marlena.vvi.at>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200503010145.j211jF1s046188@marlena.vvi.at>, "ALeine" writes: > >I find using a single key for the whole disk less secure and not >very practical when one wants to change the key because it takes >a very long time to re-encrypt the entire disk. However, having >a separate per-sector key which is changed on every write seems >to go too far in the opposite direction, so IMHO the best solution >would be to use the same key for a definable number of sectors >(set at initialization) and then having a sysctl variable to >control after how many writes you want the key changed. This >would speed things up quite a bit and users would be allowed to >decide how much assumed security they are willing to sacrifice for >noticable speed. This would also make it possible to implement my >key shadow sector idea without a performance penalty in comparison >to the current implementation of GBDE. > I confess that I still don't see the threat model here. What sort of cryptanalytic breakthrough would make this a requirement? I will state categorically that I know of no threat to AES that would be addressed by this, but wouldn't require replacing AES entirely. The canonical example is "encrypting too much data with the same key". That can be a real concern. With DES or 3DES (or any other cipher with a 64-bit blocksize), one should never encrypt more than 8*2^32 bytes -- about 32G -- with a single key if you're using CBC mode. The corresponding figure for AES is 16*2^64 -- a *much* larger number, and one well beyond any conceivable disk drive. Historically, there have been ciphers that were attackable with lots of traffic, but typically the issue was repetition of the key stream. That's not going to happen here. I leave as an exercise for the reader computing just how unlikely it is -- but it's *very* unlikely. Remember that we're dealing with 128-bit input blocks. It is, of course, conceivable that someone will find a way to use hundreds of gigabytes of data encrypted with one key to find some shortcut attack on AES -- perhaps 2^112 trials instead of 2^128. Given the reaction in the cryptographic community to the SHA1 attack, which cuts the time to 2^69 from 2^80, I'm quite confident of what would happen: a replacement for AES. That said, if you were concerned there's a very simple solution: to encrypt block B with master key K, calculate some cryptographic function F(K, B) -- ECB encryption is the obvious choice -- and use that as the block key. Use F'(B) or F'(K, B) to get the per-block IV. Add any wrinkles you want, such as caching F and F' values, or having F apply to a range of blocks. I see no need to rekey the disk. I do see a need to change the user-specified key, but that can be handled by a layer of indirection. If there were some sort of compromise that made you want to rekey the entire disk, having per-block keys won't help; you still need to read, decrypt, re-encrypt, and rewrite each block, since any likely compromise scenario would involve compromise of the key block as well. There's a school of cryptographic design that tosses in mechanisms on the vague hunch that there's threat out there. Unless you understand the threats and the tradeoffs, though, you're likely to make matters worse, not better. Often, there is no perfect solution, but if you don't understand the *real* threats you'll make the wrong tradeoffs. It's worth noting that there is a very real threat not addressed here: detecting unauthorized changes to an encrypted disk. For a very elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050301221511.3423C3C023E>