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.
Fortunately, we are lucky with signatures.
* We know that most of deployed applications support SHA-256 already,
the code is written and tested.
* We can assume that when an applications understands ECC keys, it
understands SHA-256.
* Although there are smartcard hardware vendors today that insist on
exclusively using SHA-1, they only support RSA keys.
(We hope their new release with ECC support will not have hardcoded 20
bytes + ASN.1 prefix size check.)
It follows then that:
** Self-signatures can use SHA-256. (If an applications doesn't
understand SHA-256, it doesn't understand ECC.)
** Because the key's self-signatures must be verified, data signatures
and certifications with ECC keys can use SHA-256.
** Certifications on RSA/DSA keys with ECC keys can use SHA-256 too.
** Back signatures by subkeys can use SHA-256 too.
So, SHA-1, which is too weak for any curve in this proposal, can be
safely disallowed for generation or verification of signatures made by
an ECC key. Applications should be tolerant to SHA-1 on other keys or
existing structures.
David Crick wrote:
On 3/1/08, Daniel A. Nagy <nagydani(_at_)epointsystem(_dot_)org> wrote:
I think, Andrey makes a very important point here. The option to use 3DES
symmetric encryption, SHA1 digest and ZLIB compression must remain open until
a formal process of phasing them out is initiated, with a clear road map.
Right now, excluding these algorithms would break interoperability in a very
bad way, as described by Andrey.
as someone said about alternative V5 key routes - let's absolutely
make sure we break it!
Of course, SHA1 and 3DES are not without problems, but for most
security-critical applications they are still perfectly adequate.
SHA1 is due to be retired in 2010 (at least for US Federal agencies).
That means 1024-bit DSA keys are due to demise soon. The most
recent bruteforce of RSA was on a "special" form of ~1024-bit keys
(2^1039 -1); no doubt the normal form will fall in the not too
considerable future.
Germany has apparently said 1024-bit crypto is no longer allowed
as of 2008 (this was posted regarding OpenPGP smartcards on
one of the gnupg mailing lists).
CSE say 80-bit ciphers will no longer be acceptable for Protected
A & B information from 2010 (for protected C it was 2005) and
that for A & B pk modulus 1024 will no longer be acceptable from
2010 (again, for C it is already 2048 minimum).
The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers!
That means our applications (and RFCs) need to be updated to
reflect this (*now!*; someone tell SSL web site maintainers...).
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.
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.
...