Re: ECC in OpenPGP proposal, forth revision

David Crick wrote:
...
> >  >>  > I think section 12 also needs to explicitly deprecate AES-192,
> >  >>
> >  >>  I hope that we find a consensus in not explicitly promoting AES-192
> >  >>  instead.
> >  >
> >  > For SSL it was decided to just go with AES128 and AES256:
> >  >
> >  > "The AES supports key lengths of 128, 192 and 256 bits.
> >  > However, this document only defines ciphersuites for 128-
> >  > and 256-bit keys. *This is to avoid unnecessary proliferation
> >  > of ciphersuites.*" (rfc3268)
> >  >
> >  > (Similarly, with Camellia added to SSL again only the 128 and
> >  > 256 length keys were added (rfc4132), again mentioning
> >  > that just the 128+256 are being done, despite 192 exisiting.)
> >  >
> >
> >  TLS does have a problem of explosion of ciphersuites, something that
> >  OpenPGP doesn't.
I meant the space exhaustion. 4 dimensions DH/public alg/symm.alg/hash 
alg got some people worry about depletion of 16K space. There is no 
comparable problem faced by OpenPGP.
> I beg to differ!
>
> We currently have 8 (including patent-encumbered IDEA,
> and counting each of the AESes separately) ciphers, and
> look like we will be adding a further three Camellias too.
>
> I think that rfc3268's sentiments that I quoted above are
> highly admiral, and the decision to add only 128- and 256-
> bit Camellia further, and correctly, continues this policy.
I never disagreed with benefits of eliminating as many options as we 
can. This goal is high on my list. The performance of AES-256 is not the 
bottleneck for most of applications that run on PCs and servers, which 
are bound by IO or public key crypto in realistic applications.
>  At the same time, NSA employees submit other curves outside of Suite-B:
> >  http://www.faqs.org/rfcs/rfc4753.html
> we've *got* three NIST-approved ECC curves for each
> of the AES size keys, two of which are Suite B / NSA
> approved.
>
> Until there is either a market demand - *or* technical
> or security considerations - that would warrant looking
> at those other curves, then they're not even on my
> radar.
>
> >  Plus, a controversial decision to use weaker ECC curve with AES-256...
> You've got this *completely* the wrong way around!!
>
> The flow was:
>
> 1. NIST blesses AES for sensitive information
> 2. NSA says AES128 is OK for SECRET, and 192 *and*
>     256 good enough for TOPSECRET.
> 3. NSA reveals Suite B, including suitable suites for
>     SECRET and TOPSECRET use, the TOPSECRET
>     cipher being AES256, the other components being
>     the lower of *two valid* possible sets for TOPSECRET.
>
> Now, NSA give "interoperability" as their reasoning for
> excluding AES192; we can only guess what that means.
>
> But anyway, what they've done is chose *a* TOPSECRET
> strength for the public key and hash, and *a* TOPSECRET
> cipher. And this is for *Their* use, so it's damned well gotta
> be strong enough.
>
> The *fact* is that the cipher is *stronger* - *not* that
> they've "picked" a weaker hash/public key curve.
It's a valid view angle. That's probably how AES-192 was "upgraded". So 
is another one -- ECC-521 is missing from Suite-B that is needed to 
perfectly match Suite-B symmetric algorithm today. Going forward, it is 
the public key algorithms that "age" faster than symmetric algorithms as 
processors get faster and mathematicians smarter. My use of "weaker" was 
in this forward looking meaning.
> (And in fact up until now in PGP we've generally had higher
> strength ciphers compared to public keys (2.6 with 128 IDEA
> and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).)
>
> So I don't think your argument holds, and if anything
> actually *supports* AES256 over AES192.
>
> But anyway...
>
>
>
> >  I essentially added what you've asked regarding AES-192. Not outright,
> >  but with a premise that you and Ian are using, which is, if we see the
> >  world as divided into "weak" and "strong" systems, "strong" systems
> >  SHOULD use AES-256.
> I'm not quite happy with the wording - I think it needs to be more
> "against" - plus, by having a single, clear sentence or two that
> simply states:
>
>   "please note, use of AES192 is deprecated.  You should only
>   consider using it if you have very specific requirements."
>
> would actually cut out a *lot* of our current "advisory verbiage."
I wish we had mobile/smartcard people voice their opinions, since
AES-192 is for them. It is hard to advocate on their behalf, because 
once you go down the path of less processing power, the diversity of 
systems increases (use diversity of smartcards as a proof).
Nonetheless, for what a generic statement is worth, suppose AES-128 was 
X dollars (or cents?) cheaper than AES-256 to support in a given device 
and a vendor chose AES-128 only. If for whatever reason AES-192 or 
better must now be supported, the vendor's choice is to accept X/2 extra 
cost for AES-192 or X for AES-256. Will X/2 saving achieved with AES-192 
matter for mass-produced devices like smartcards? Probably. The support 
for AES-192 is not an issue for this vendor, because another side is 
likely more capable system that implements every AES algorithm.
( I assumed above that crypto throughput scales proportionally for AES 
128/192/256, as my previous email indicates, and that the cost per unit 
is likewise proportional ).
> *But*, having at least got *some* sort of wording into the draft
> about AES192, I'm *somewhat* "placated" - even if I'd (still)
> prefer it stated more strongly (*and* simply!).
That's a great relief, David. I will continue to think about how to make 
it closer to what everybody has requested.
> But anyway (again)...
>
>
> >  Thank you.
> And again my thanks to you too - for helping us to bring ECC
> to PGP.  I just want to try and do it in the best way possible!
I appreciate your comments, as well as anyone else's. That's not the 
last time I say thank you, of course.
> I *still* think that some of the "security recommendations"
> should be liberally sprinkled directly into each of the specific
> algorithm sections.  This would make each section more
> readable in its own right, and would enable us to convert
> section 12 into a more general guidance section, rather than
> how it is now, with guidance *and* specific recommendations.
>
> However, it's your document!, and you've already stated that
> you feel that it would be better the way you've structured it.
>
>
> I really do think we've pretty much got the technical/application
> level stuff fairly well hammered out now, and that's it's near to
> the consensus [conflicting opinions ;) ]  that we're aired.
>
> So from my point of view I think it's just honing the language
> and structure of the document that remains - seeing if we can
> more clearly and concisely put it across.
I put more weight on succinctness. This often goes against clarity. I do 
have preference against redundancy. In any case, I would appreciate 
suggestions on how to improve readability.
> 4880 is a highly readable RFC; I'd like to think we can make
> the ECC document just as consumable.
Assuming we agree on technical details/options, is there interest in 
test vectors? Some methods, such as those used with ECDH, are 
parameterized uniquely, leaving implementers will no reference to check 
their code. Test vectors will help mitigate the concern of the multitude 
of options; this will increase the speed of adoption and reduce bugs. It 
may delay the progress of the document and put more burden on author(s). 
Alternatively, test vectors can be posted elsewhere. What does the group 
think about the value/route in this respect?
Thank you.