Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

Ian wrote:

> Hmmm... you raise an interesting point. I had thought that this
> was going to be a new document, and as it is not referred to in
> the existing core RFC, then ECC/Suite B was going to be a MAY by
> definition.
>
> Within that new (MAY) document, there would be several choices
> for MUST, SHOULD, MAY, etc.
>
> Or so I thought ... but I'm not fully aware of how these things interact.

and further:

> > I don't see how we can simplify past dropping 192.
>
>
> OK, if you are happy to carry on this discussion ... what are the
> reasons for including the 128-bit profile?

assuming the may -> whatever chain above holds, what about:

MAY implement ECC
  o MUST implement AES256-SHA384-384ECC
  o SHOULD implement AES128-SHA256-256ECC
  o MAY implement AES256-SHA512-521ECC
    [and/or any other combinations, but these might be "unbalanced"]


we currently *have* 3072 RSA/DSA strength (or 4096 RSA/ElG for
those wanting a bit of extra headroom); higher size DSA isn't in
any [e.g. NIST] standard, and >=4K RSA/ElG public key ops begin
to take a noticeable time even on my desktop (so while 7K RSA
keys are a simple source-change in GnuPG, ECC would definitely
make sense to achieve a balanced crypto system at this strength).


Now, for "embedded"/constrained systems there may only be the
chance to do AES128-SHA256-256ECC, which would conflict with my
"SHOULD" suggestion above.  So there would probably be scope for
the AES128 set to be a SHOULD as well, or even the MUST instead.


To be honest I think having AES256-SHA384-384ECC *and*
AES128-SHA256-256ECC in *some* form of MUST/SHOULD *is*
desirable: it covers both the two "Suite B" available
balanced set of algorithms, which may be important to
some people (and is certainly more "marketable" anyway).


I wouldn't personally "protest" if AES256-SHA512-521ECC
were also included, but I think anything more than these
three balanced sets is "silly."