sorry, I did "reply to Ian" rather than reply to all (including the list),
which I meant to do.
---------- Forwarded message ----------
From: David Crick <dacrick(_at_)gmail(_dot_)com>
Date: Mar 4, 2008 4:07 PM
Subject: Re: ECC in OpenPGP proposal
To: Ian G <iang(_at_)systemics(_dot_)com>
On 3/4/08, Ian G <iang(_at_)systemics(_dot_)com> wrote:
Andrey Jivsov wrote:
>
> Let me explain my choices in this respect in the ECC proposal.
>
> We need 3DES as a fallback default to smoothly integrate ECC keys into
> existing installed base, as I mentioned earlier.
Can you say more about this? I do not see any reason to
specify 3DES with ECC.
(Yes, I know it is in RFC4880. I just don't know what that
has to do with a separate ECC proposal.)
The argument has been that if we are to "add" ECC *onto*
OpenPGP (which for the WG means "RFC4880") then we
"MUST" implement 3DES.
If we wanted to create an ECC-*only* standard or application
then no 3DES would be fine, but it wouldn't be compliant with
4880 or (necessarily) interoperable with an OpenPGP application
(which might only understand 3DES) or respectful of a user's
[existing] key preferences.
We all know that 3DES should be retired in favour of AES.
This means, in principle, not to write it into any new
proposals, and smooth the way forward to let the
implementors phase it out.
NIST have handled it this way:
FIPS46-3 has been withdrawn.
FIPS187 is the standard, which you are *encouraged* to use.
3DES has been taken out of FIPS46-3 and issued as a (lesser)
"special recommendation". 3DES lifetime is until 2030.
Therefore, NIST say 3DES is OK but that AES is the preferred
choice.
*We* (4880) say that 3DES is a MUST and that AES128 (and
CAST5, which CSE are also OK with) are SHOULDs.
*NSA*, meanwhile, say that for *classified* stuff you may use
any of the AESes, but that for TOP SECRET you must use
one of the larger. Further, they specify PK strengths, which
at these lengths are ECC rather than absurdly big IFP/DLP
RSA/DH ones.
So, now that we are coming to implement ECC in OpenPGP,
we naturally want to base things on the NIST/NSA guidelines,
as well as considering implementation limitations and market
requirements.
We also have our OpenPGP history to take into account.
So this means that have to support the 4880 MUSTs to
remain compatible with current applications and user base.
The installed base is about private/public keys. They
*will* create the ECC keys any way you tell them. If you
don't tell them to set a preference for 3DES ... they won't
do it.
Or have I got something wrong?
that 3DES is an implied preference, even if not there.
>> 3DES is more of a "problem" - it's set to co-exist with AES until
>> 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto
>> we've still got 3DES as our OpenPGP vestigial tail.
Sure. Leave it there in RFC4880. That's history.
Or are you telling us that Suite B mandates 3DES???
no, Suite B doesn't mandate 3DES it doesn't.
If we want to integrate into/with the current 4880 then
3DES needs to be in[herited in!] OpenPGP-ECC.
I'm not "over-joyed" by this, but if my "longer keys are
preferred" bit is added onto the "SHOULD try and match
sym. and pub. key lengths" bit then that's about as near
to the "encouraging" of AES over 3DES as we are likely
to be able to get.