Peter wrote:

Yup. Actually the no-stored-IV encryption was never designed to be a non- malleable cipher mode, the design goal was to allow encryption-with-IV without having to explicitly store an IV. For PWRI it has the additional nice feature of avoiding collisions when you use a 64-bit block cipher, which is probably going to be the case for some time to come even with AES around. It was only after all that that I noticed that the first pass was effectively a CBC-MAC, but it didn't seem important enough to mention it in the RFC since it wasn't an essential property (good thing I didn't :-).

...

With a disk mode, unlike with RFC3211 password based encryption for CMS there is no place to store the structure inside the plaintext which may to some extent defend against this attack.

Here is a partial list of requirements that I believe apply to drive encryption cryptographic systems. I am sure that list is incomplete and may contain errors. The following is what springs to mind: 1) I do not believe that there is a fundamental need to limit the size of the ciphertext to the size of the plain text. Adding a 1% or even more space overhead for encryption is acceptable under any day-to-day scenario that I can think of. 2) The algorithm must be able to decrypt individual sectors without having to decrypt the entire contents of the drive. Nor must the algorithm leak any plaintext, even if the attacker were to have knowledge of all but one byte of the plaintext stored on the drive. 3) The encrypted partition should leak no information about the number, nature, and size of any files stored on the drive. Unless one has access to the key, the entire partition should be appear to the observer as a homogenous block of opaque encrypted data. 4) It would be nice, but is not in the least required, to be able to convert an existing unencrypted partition to an encrypted partition and back. 5) It must be possible to pass the encryption key as a parameter to mount, presumably in the form of a config file containing they key to prevent the key from showing up in ps. 6) It should be possible to both specify a raw AES key as well as a passphrase-derived SHA2 generated AES key. 7) Since the key will need to be stored in RAM for extended periods of time, the key should be protected from forensic recovery by being never being swapped to disk as well as by periodic bit-flipping. 8) Ideally, and this is definitely a feature for v2.0, each user would be able to specify a capability that will permit the listing and access of any files under that user's permissions on the encrypted file system. 9) While steganographic file systems offering multiple levels of credible distress keys are nice, I don't consider this a feature that should be included in v1.0.