Subject: Re: RFC: backporting GEOM to the 4.x branch
To: ALeine <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 03/01/2005 17:15:11
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