Threat Model
> > 2. Is there a summary of the threat model against which the encryption
> > is intended to defend?
>
> This is intended to protect the privacy and defend against the
> malleability of the ciphertext.
>
> The attackers are
>
> 1. Passive observation of SAN traffic.
>
> 2. Access to the storage (either by accessing the SAN or getting the
> storage medium itself).
>
> 3. Active man in the middle on the SAN (changing the command and/or
> data).
>
> 4. Active modifications to the storage system either via the SAN,
> backdoor into the storage system or removal and reinstallation of the
> storage.
So from the perspective of the crypto function I would summarize
the above as the following two points and add a third point.
1. Observing the cipher text should reveal the minimum possible
information about the corresponding plain text.
2. An attacker modifying the cipher text should have minimum
possible control of the resulting plaintext. Specifically,
replay and randomizing attacks should be the only possible.
3. Launching a concentrated chosen plain text and chosen cipher text
attack on a particular sector should give no information about
any other sectors.
Interestingly, the following scheme comes pretty close to meeting these
requirements. Use a linear mixing function followed by "tweaked" ECB.
Regarding requirement 1, any normally occurring change to plain text
will cause an apparently random change to cipher text. Clearly this
is not true of a chosen plain text, but resistance to chosen plain text
is not a requirement to meet #1.
Any simple modification to the cipher text will result in apparently
random modification to the plain text with certain qualifications.
An important qualification is that "apparently random" means apparently
to any upper level checking that may occur. Changing a single
block of cipher text would of course randomly perturb the plain text
only within a small linear sub-space, but this looks random to any
application not specifically checking for this.
For an attacker that can mount a chosen plain text attack, requirement
2 does not apply since the attacker can trivially forge anything he
wants.
However, an attacker that can compile a list of know plain text cipher
text pairs, and do some mixing and matching of cipher text sub-blocks,
can create cipher text that decrypts to a somewhat controllable but
not previously observed plain text. This is probably a fatal flaw
even though I tend to regard randomizing and
replay attacks as potentially more damaging.
===========================================================
An interesting variation of the above is to consider what happens when
64 bits of block guard information are included in the sector. The
requirement then becomes that any change to the cipher text must result
in an apparently random change to the plain text block guard. The
effect on the other parts of the plain text are not important. This
significantly improves security, too, by preventing (more accurately
catching) randomizing attacks which may be the biggest threat in reality.
===========================================================
Interesting question: How could the EME algorithm be optimized
if the following changes were made to the requirements?
1. Include 64 extra bits of check information to each sector.
2. Require only that normally occurring changes to plain text
result in apparently random changes to cipher text. Chosen
plain text variation that are not likely to occur in practice
need not randomize the resulting plain text.
3. Any change to cipher text must result in apparently random
change to check information plain text. It is not necessary
that changes to other parts of plain text be apparently random.
4. Changes to the cipher text of the check information changes
only the check information plain text. This allows use without
check information at the expense of protection against modification
attacks.