Nomen Nescio <[EMAIL PROTECTED]> writes: >Peter Gutmann and Colin Plumb invented a simple trick which provides this >property in conjunction with CBC or CFB modes. We're going to encrypt/decrypt >a disk block, which is divided into "packets" which are the cipher block size >(64 or 128 bits). Let P[j] mean the jth packet of plaintext in the block; >assume there are n packets in the block. C[j] is the jth packet of ciphertext. > >Encryption > >P[n] ^= Hash(P[1..n-1], blocknum, diskID) >Encrypt block using P[n] as IV > >Decryption > >Decrypt C[2..n] using C[1] as IV >Decrypt C[1] using P[n] as IV >P[n] ^= Hash(P[0..n-1], blocknum, diskID) > >The idea is to use P[n] as IV, first xoring in some function (doesn't have to >be a crypto hash) of the first n-1 packets, the block number, and some disk- >specific value. Doing this ensures that the IV depends on all the bytes in >the block, so a change to any byte will change the entire block. The >decryption doesn't have to be split into n-1 and 1 block parts as shown here, >any division will do.
Actually it's more general that that, the reason the original implementation used such a simple first pass was because it had to run on things like 385/25's which weren't too fast doing two passes of encryption. For anything more recent, you'd do two passes of encryption, the first to build the IV and the second to encrypt with it. This in effect means that the first pass is a MAC of the data (alongside encrypting it) and the second pass is pure encryption. This gives you some nice provable security properties which Phil Rogaway and Mihir Bellare have done some work with (see http://www.cs.ucdavis.edu/~rogaway/papers/index.html and http://www-cse.ucsd.edu/users/mihir/papers.html for some publications). This is the approach used in RFC 3211, which I'd regard as the proper (unconstrained by having to run on a slow CPU) way to use the technique.. (I'm kinda surprised that this issue keeps coming up again and again, Colin's design is a general-purpose solution which works with any block cipher. It's a solved problem, and has been so for about a decade). While I'm on the topic, I'd also like to question the implicit assumption that speed is the principal design target. Having a lot of experience with disk crypto on (by current standards) very slow machines, I must say that speed has never been a problem for me. Right now I'm doing software-based 3DES and I can't even notice that the drive is encrypted. Now if you're encrypting swap and your system is thrashing I can see that you'd notice, but for the average user who barely accesses the disk and who's running a modern OS which does sensible buffering/cacheing, it really isn't an issue. Far better to concentrate on flexibility and security than to drop everything so you can chase after this single red herring. Peter.
