ECC in OpenPGP proposal, forth revision


David Crick wrote:

On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov 
<openpgp(_at_)brainhub(_dot_)org> wrote:

David Crick wrote:
 > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated
 > (this *is* mentioned in section 12, but would like to see it here too)


are you not going to add "MAY .. curve 2" into 11.1?

both Ian and I have requested this, and I have previously
pointed out that for *all* algos (asym, sym, hash) 4880
adds a "MAY implement any other" to the end of each
section (where for ours, there IS only one other, so may
as well be mentioned specifically, i.e. MAY curve 2)


Done.

...

 > 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. (Can I be more overzealous in consensus building?).

 > Again, I see what you're trying to say, but as is noted elsewhere in
 > the ECC doc, it's merely the intersection - it's up to the implementation
 > to make its own decision thereafter (and so take advantage of any
 > ordering information).

 As a side note, per RFC4880 this "is an ordered list of octets with the
 most preferred listed firs". If each recipient has the same set of
 symmetric algorithms, shouldn't the intersection remain ordered? I think
 "merely an intersection" is not strictly correct, although I can agree
 with "in practice" or "in most cases" clarification.


... I was referring to THIS bit in 4880 (13.2):

"The implementation may use any mechanism to pick an
  algorithm in the intersection."

Thus, while the section you quote (5.2.3.7) is *also* correct,
what 13.2 is saying is "well, there's information you COULD
use, but it's really up to you [the implementation] to pick an
algorithm."


Therefore, I was *happy* with your original wording (and would
prefer to see it re-instatad!), but was just pointing out that it
was only part of the (i.e. [4880] rfc) story.


OK, the above clears this one.

 > I think section 12 also needs to explicitly deprecate AES-192, saying
 > that it's not necessarily going to be fielded widely (bring in the fact
 > that it is only a MAY here might help), isn't one of the Suite B ciphers,
 > and that it's probably only suitable if for some reason you *really*
 > need a 192-bit cipher: otherwise go for AES256 for security or -128
 > for performance.

 I hope that we find a consensus in not explicitly promoting AES-192
 instead. There are many reasons why mobile/weak hardware devices may
 wish the middle-of-the-road approach with AES-192/ECC-384.


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 thatOpenPGP doesn't. I recall that one of main technical reasons ofpreferring one Open PGP auth. spec to another in the past was this issue.

With Suite B, NSA have chosen to also just go with 128 and
256, despite the other elements of the larger algo set being
192-equivelent in size.  From their footnote 1:

"CNSSP-15 correctly states that 192-bit AES keys are sufficient
for protecting even TOPSECRET information. However, Suite B
uses only 256-bit keys *to enhance interoperability*."


At the same time, NSA employees submit other curves outside of Suite-B:

http://www.faqs.org/rfcs/rfc4753.html

Plus, a controversial decision to use weaker ECC curve with AES-256...


Our MUST is AES-128, our SHOULD is AES-256.  I think we should
be following the trend in promoting just 128 and 256 bit ciphers,
and by deprecating AES-192 - which we NEED to do with the
stronger Suite B set (perhaps possible the "only" reason to
implement Curve 2, give our MUST on C1 and SHOULD on C3).

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 theworld as divided into "weak" and "strong" systems, "strong" systemsSHOULD use AES-256.


Thank you.


The latest version is:
   http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-9.txt

The same version in other formats:
   http://brainhub.googlepages.com/pgp