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
