On Mon, Mar 17, 2008 at 11:57 PM, Andrey Jivsov
<openpgp(_at_)brainhub(_dot_)org> wrote:
>> David Crick wrote:
> are you not going to add "MAY .. curve 2" into 11.1?
>
> both Ian and I have requested this ...
Done.
thank you.
>> > 12 "It is generally advisable to list at the head of the preference
list
>> > a symmetric algorithm of strength corresponding to the public key."
>>
>> I watered down this statement to leave that at least the algorithm
>> should be there.
>
> I *preferred* the original version ("at the head")! ....
Reversed.
again, thanks.
>> > 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 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.
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.
(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."
*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!).
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 *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.
4880 is a highly readable RFC; I'd like to think we can make
the ECC document just as consumable.