These techniques remind me of Lion and Bear (http://www.cl.cam.ac.uk/ftp/users/rja14/bear-lion.ps.Z). Lion is pretty fast, too, with the right parameters (of a stream cipher + hash function). It would be easy to modify either to take a block count so you wouldn't need to store the extra IV. Just another thing to think about, I guess. -J
On Sun, 28 Apr 2002, Adam Back wrote: > On Sun, Apr 28, 2002 at 06:22:22PM +1200, Peter Gutmann wrote: > > Anonymous writes: > > >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) > > I saw something similar also discussed which was: > > Encrypt: > > iv1 = hash(blocknum, diskID, P[2..n]) > iv2 = C[1] = Encrypt(iv1,P[1]) > C[2..n] = Encrypt(iv2,P[2..n]) > > Decrypt: > > iv2 = C[1]; P[2..n] = Decrypt(iv2, C[2..n]) > iv1 = hash(blocknum, diskID, P[2..n]) > P[1] = Decrypt(iv1,C[1]) > > which seems essentiall the same. > > > 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. > > So if you mean the approach in 1311 you referenced below: > > | Key wrapping: > | > | 1. Encrypt the padded key using the KEK. > | > | 2. Without resetting the IV (that is, using the last ciphertext > | block as the IV), encrypt the encrypted padded key a second > | time. > | > | The resulting double-encrypted data is the EncryptedKey. > | > | 2.3.2 Key Unwrap > | > | Key unwrapping: > | > | 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th > | ciphertext block. > | > | 2. Using the decrypted n'th ciphertext block as the IV, decrypt > | the 1st ... n-1'th ciphertext blocks. This strips the outer > | layer of encryption. > | > | 3. Decrypt the inner layer of encryption using the KEK. > > are you sure it's not vulnerable to splicing attacks (swapping > ciphertext blocks around to get a partial plaintext change which > recovers after a block or two)? CBC mode has this property, and this > mode seems more like CBC in CBC than a CBC-MACed CBC-encrypted message > -- there can't be a MAC property as such because there is no where to > store one, so the best you could hope for is earch byte of plaintext > depends on each byte of ciphertext, and this is the property I'm > questioning based on the usual CBC splicing attacks. > > > (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). > > What is Colin's design and where is it described? > > Adam
