[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-02-29 14:45:09

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

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]).

<Prev in Thread] Current Thread [Next in Thread>