I think that the scope of ECC document is not to define the perfect
combination of symmetric algorithm/hash/public key algorithm. The issue
of relative strength applies equally well to RFC 4880. We should discuss
the relative strength issue and how the ECC fits into this and we can
recommend certain combinations, but should avoid mandating exact
permutations. These combinations are not permanent and subject to
opinions, mostly because of public key component. Balanced today
AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future.
Let's also not forget about the issue of encoding to multiple
recipients. Remember that the message gets encoded to a single symmetric
key. "Walking up" from this algorithm, which may be other than AES (in
fact, the 3DES is the fallback default), we may legitimately end up with
pairs of symmetric/public tupples that don't match the "perfect"
profile. In other words, if we have two recipient keys:
ECDH public key symm. alg
--------------------------------------------
P-256 AES-128, CAST5
P-521 AES-256, AES-128
RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In
some cases we cannot "insist" on using a particular algorithm.
I think the best way to add longevity to this document is to pick up a
few core permutations and then make its *components* MUST. In
particular, there seem to be consensus on Curve ID 1 as MUST. I also
have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle
the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing
this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is
SHOULD and not MAY because of multiple recipient issue (if it is MAY to
generate P-384, it is effectively MUST to be able to encode to it).
David Crick wrote:
On 2/29/08, Ian G <iang(_at_)systemics(_dot_)com> wrote:
David Crick wrote:
> How hard-coded do we want/need to make the[se] cipher-hash-curve
> combinations? For Suite B compatibility/marketability we need
> them "fixed" (especially in light of pointing out the higher
> relative MAY cipher size) and the hash fixed as SHA2 (as opposed
> to, say, a hypothetical Whirlpool; SHA3 could be added later).
Me: hardcoded. Nobody ever showed that SHA wasn't good
enough for the job and NIST/NSA is happy with it, until 2012.
...
If the Europeans want to propose a EuroSuite, let them.
Let's not jump on the bandwagon and make the profile
all-things-for-all-humanity.
I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2.
*I* would also be 100% happy fixing the cipher sizes with only AES.
*However*, are we ( <waits for other people to pipe up> ) willing to
insist that for OpenPGP ECC you *absolutely* MUST use AES *and*
at these specific sizes for the corresponding algorithm sets below?
MAY implement ECC
o MUST implement AES128-SHA256-256ECC
o SHOULD implement AES256-SHA512-521ECC
o MAY implement AES256-SHA384-384ECC
Aside from the side-effect of 4880 (and predecessor's) 3DES MUST,
this would be the first time that we are mandating specific cipher
usage. We're not saying "SHOULD" (and WARN the user if they do
otherwise), we're saying MUST. (A watered-down compromise would
be to say "for Suite B compliance, AES MUST be used," just as we've
said for DSS compliance SHA must be used [and at certain sizes]).