attack on rfc3211 mode (Re: disk encryption modes)

[Lucky Green]

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.