On Fri, Apr 26, 2002 at 11:48:11AM -0700, Joseph Ashwood wrote: > From: "Bill Stewart" <[EMAIL PROTECTED]> > > I've been thinking about a somewhat different but related problem lately, > > which is encrypted disk drives. You could encrypt each block of the disk > > with a block cypher using the same key (presumably in CBC or some similar > > mode), but that just feels weak. > > Why does it feel weak? CBC is provably as secure as the block cipher (when > used properly), and a disk drive is really no different from many others. Of > course you have to perform various gyrations to synchronise everything > correctly, but it's doable.
The weakness is not catastrophic, but depending on your threat model the attacker may see the ciphertexts from multiple versions of the plaintext in the edit, save cycle. This could happen for example the attacker has read access to your disk, or if the attacker gained temporary physical access to the machine but didn't have enough resources to install software trojan, or if good disk checksumming is in place, didn't have enough resources to install hardware trojan. > > So you need some kind of generator of pretty-random-looking keys so > > that each block of the disk gets a different key, or at the very > > least a different IV for each block of the disk, so in some sense > > that's a PRNG. (You definitely need a different key for each block > > if you're using RC4, but that's only usable for Write-Once media, > > i.e. boring.) Obviously you need repeatability, so you can't use a > > real random number generator. > > Well it's not all the complicated. That same key, and encrypt the disk > block number, or address or anything else. Performance is often at a premium in disk driver software -- everything moving to-and-from the disk goes through these drivers. Encrypt could be slow, encrypt for IV is probably overkill. IV doesn't have to be unique, just different, or relatively random depending on the mode. The performance hit for computing IV depends on the driver type. Where the driver is encrypting disk block at a time, then say 512KB divided (standard smallest disk block size) into AES block sized chunks 16 bytes each is 32 encrypts per IV geenration. So if IV generation is done with a block encrypt itself that'll slow the system down by 3.125% right there. If the driver is higher level using file-system APIs etc it may have to encrypt 1 cipher block size at a time each with a different IV, use encrypt to derive IVs in this scenario, and it'll be a 100% slowdown (encryption will take twice as long). > This becomes completely redoable (or if you're willing to sacrifice > a small portion of each block you can even explicitly stor ethe IV. That's typically not practical, not possible, or anyway very undesirable for performance (two disk hits instead of one), reliability (write one without the other and you lose data). > > I've been thinking that Counter Mode AES sounds good, since it's easy > > to find the key for a specific block. Would it be good enough just to > use > > Hash( (Hash(Key, block# )) > > or some similar function instead of a more conventional crypto function? > > Not really you'd have to change the key every time you write to > disk, not exactly a good idea, it makes key distribution a > nightmare, stick with CBC for disk encryption. CBC isn't ideal as described above. Output feedback modes like OFB and CTR are even worse as you can't reuse the IV or the attacker who is able to see previous disk image gets XOR of two plaintext versions. You could encrypt twice (CBC in each direction or something), but that will again slow you down by a factor of 2. Note in the file system level scenario an additional problem is file system journaling, and on-the-fly disk defragmentation -- this can result in the file system intentionally leaving copies of previous or the same plaintexts encrypted with the same key and logical position within a file. So it's "easy" if performance is not an issue. Another approach was Paul Crowley's Mercy cipher which has a 4Kbit block size (= 512KB = sector sized). But it's a new cipher and I think already had some problems, though performance is much better than eg AES with double CBC, and it means you can use ECB mode per block and key derived with a key-derivation function salted by the block-number (the cipher includes such a concept directly in it's key-schedule), or CBC mode with an IV derived from the block number and only one block, so you don't get the low-tide mark of edits you get with CBC. But Mercy as a set of design criteria is very interesting for this application. Adam -- http://www.cypherspace.org/adam/
