Declan writes:
>     Their beef: If two Windows 2000 computers without triple-DES are
>     talking and the system administrator has configured triple-DES-only
>     links, only single-DES gets used. The only error shown is an invisible
>     one -- in an audit log file -- so users may have a false sense of
>     security.

While there's no excuse for this and everyone involved deserves to be
embarrassed and ashamed, this bug is an example of a class of mistake
that is very easy to make when implementing protocols that are
designed to provide multiple levels of security.  It is often possible
to negotiate accidently (or with help from an external attacker) an
insecure set of parameters for an otherwise secure protocol, with no
obvious side-effects and no way for the applications that depend on
it to know.  This is especially true when the protocol lives low
in the stack (e.g., in the file system or, as in this case, at the
network layer), where applications have little control over or
communication with the security services.   In the absence of
information to the contrary, applications really have no
choice but to assume that the security services on which they are
depending always operate in the lowest-security configuration possible.

This is why, in spite of all the arguments about the desirability of
"having a backup" cipher available in case one is proven to be weak,
I oppose the idea of selecting multiple algorithms for AES.  If the
standard has two algorithms, everyone will have to implement both,
and in most applications it will be impossible in practice to
know (or even influence) reliably which one is actually being used,
so prudent designers will have to assume that it is always the
weakest one.  If one of the algorithms turns out to be weak,
implementations will have to be fixed to remove it anyway, with
all sorts of ambiguity over what is being negotiated before
everyone has ripped out the offending cipher.  If AES is only
one algorithm (at a time), a lot of potential transition problems
are avoided, since "fixed" implementations simply wouldn't
interoperate with "broken" ones.

-matt



Reply via email to