Adam Back <[EMAIL PROTECTED]> writes: >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.
It is a CBC MAC. A CBC MAC encrypts n blocks and then takes the final output as the MAC. Now look at where the IV for the second pass comes from. It's a nice trick, because it works without any data expansion. >What is Colin's design and where is it described? Originally in a sci.crypt post of about 10 years ago, more recently (which isn't saying much, it was years ago) in the docs for SFS, http://www.cs.auckland.ac.nz/~pgut001/sfs/index.html. Note that this is the speed-customised version, the version which uses two passes of encryption is in RFC 3211. Peter.
