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.)
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.
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?
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???
So maybe we can mangle ECC support so that we can still use
3DES with it,or maybe we need to crack on with V5, make it ECC
only, and - as with the PGP 2 -> PGP 5 transition - have people
run parallel apps (or send multiple messages) if they want to
inter operate with 2048-3072-bit mod. non-ECC OpenPGP users.
iang