David Shaw wrote:
On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote:
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.
Well, it is not "remove 3DES" but rather move over to
AES. The attacks that were mentioned are the ones based
on the birthday attack, I do not know the details, but
it is based on the block size being too small. This
is not a validated threat but it is a signal to start
moving to a bigger block size, being 16 bytes.
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.
OK, so if we add AES as a MUST algorithm, leaving TripleDES
in place as a MUST also, then that paragraph needs to be
clarified.
Possibly:
Since TripleDES and AES are MUST-implement algorithms,
if they are not explicitly in the list, they are implied
to be at the end. However, it is good form to place the
algorithms there explicitly, and as algorithms may be
reduced in status from MUST to SHOULD in the future,
this is highly recommended. Note also that if an
implementation does not implement the preference, then
it implicitly implements the MUST algorithms.
Hmmm... that's getting clumsy. I'd say that such a default
should be deprecated, if possible:
Is there any good reason why implementations shouldn't
implement the preference? Are there any implementations
that do not implement the preference?
Also, is there any good reason to imply the MUST algorithms
into the list? Obviously there are implementations that
do this. But why not just deprecate that implication and
say that implementations MUST include all their preferences,
with a footnote that older implementations may implicitly
assume TripleDES at the end of the list?
How about:
At least one MUST-implement algorithm SHOULD be in the
list.
Older implementations may deliver an empty list, and may
imply TripleDES at the end of the list. This behaviour
is deprecated.
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.
OK, so at least we seem to have consensus on adding AES
as a MUST algorithm. Anyone else demur?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/