Re: Threat Model
owner-stds-p1619@LISTSERV.IEEE.ORG wrote on 12/04/2004
18:02:53:
> On Wednesday 31 March 2004 06:24 pm, Williams, Jim wrote:
> > [...]
> > 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.
> > [...]
>
> Jim & group,
>
> As a cryptographer, I have a problem with the approach of trying to
> identify the "security needs" of an application, and then
find the most
> efficient piece of crypto that addresses these needs and nothing more.
> I am very skeptical of our ability to understand the real "security
> needs", and claims that some form of attack "cannot really
be useful
> to an attacker" commonly turn out to be wrong.
>
> Instead, I prefer the approach of using the "strongest possible
piece
> of crypto", under reasonable performance constraints. In most
cases the
> crypto is not the most expensive piece anyway. And even when it is
the
> most expensive piece, advances in technology diminish the expense,
but
> security risks are something that you are stuck with for a long time.
>
> Specifically for our case, I seriously doubt that the difference
> between using EME and using "LRW with pre-mixing" (which
is what Jim
> describes) will be much noticeable for any application. And with EME
> you don't have to resort to claims that "this looks random to
any
> application not specifically checking for this".
>
> That said, I have to add that the same criticism also applies to EME:
> as we all know, the effectiveness of encryption is significantly reduced
> since we settle on length-preserving encryption. I was convinced
that
> in some cases the length-preservation is a non-negotiable requirement,
> but I'm still worried that we do not stress enough the limitations
of
> this approach.
>
> > ===========================================================
> >
> > 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.
>
> Well, in this case I guess the requirement would be unforgeability
of
> ciphertext (except with respect to a low setting of the security
> parameter, since you talk about a 64-bit authentication tag).
>
> > ===========================================================
> >
> > 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.
>
> I don't understand this requirement (and as I said above, I am skeptical
> of making such requirements).
>
> > 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.
>
Is there any reason somebody would want this separation
- except for the hardware designer that would like to check without
decrypting. And the later would be better served by what Shai suggests
below without having to add and additional (and possibly weakening) requirement
to crypto.
> The easiest thing would be to add a 64-bit message-authentication-code
> on top of the encryption. Optimizations are possible, of course (e.g.,
> use some variant of OCB).
>
> -- Shai