RFC: backporting GEOM to the 4.x branch

[Steven M. Bellovin]

In message <200503010145.j211jF1s046188 at xxxxxxxxxxxxxx>, "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