On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote:
On 13 Apr 2005, at 2:51 PM, David Shaw wrote:
There are too many years and too many implementations where 3DES is
the algorithm of last resort, and changing 3DES to a SHOULD
necessitates a different algorithm of last resort. We cannot change
that overnight.
I think there is a big difference between what the
implementations do, and what the standard says. If
there is an issue in the short term, then implementations
are free to ignore the standard. It's not as if anyone
ever lost a contract because they couldn't prove absolute
compliance with the standard.
In this happy state of affairs, I am not sure why we
cannot (as a standards body) wiggle our fingers with
fierceness about 3DES and have the implementations
broadly ignore us for many months or even years...
If we mean it, put it in the standard. If we don't, then don't put it
in the standard. No need for wink-wink with implementations. This is
a pretty straightforward issue. Even before 2440, in 2440, and until
today, 3DES has been the algorithm of last resort. There are a
significant number of deployed systems that base their behavior on
that design. You can't declare a flag day after which the algorithm
of last resort is different without causing incompatibility.
Where comes this desire to remove 3DES? Are there any new attacks
that raise the desire to dispose of it? The only complaint I can see
with 3DES is that it's *slow*. Not that it's insecure.
Is the "algorithm of last resort" actually specified
in the draft RFC, is it?
Section 12.1:
Since TripleDES is the MUST-implement algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. Note also that if an
implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation.
An implementation MUST NOT use a symmetric algorithm that is not in
the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking
the intersection of the preferences of the recipients. Note that
the MUST-implement algorithm, TripleDES, ensures that the intersection
is not null. The implementation may use any mechanism to pick an
algorithm in the intersection.
If an implementation
chooses 3DES as its algorithm of last resort, that doesn't
need to change. It just seems likely that in a couple
of years or so, AES would make more sense for that decision.
So add AES as a MUST implement to get it out there, and then in a few
years we can revisit what the algorithm of last resort is. Just leave
poor 3DES alone.
David