Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

On 3/4/08, Andrey Jivsov <openpgp@xxxxxxxxxxxx> wrote:
> David Crick wrote:
>  >>  We need 3DES as a fallback default to smoothly integrate ECC keys
>  >>  into existing installed base, as I mentioned earlier.
>  >>
>  >
>  > then (reluctantly, but not violently against) how about:
>  >
>  > MAY implement ECC
>  >   o MUST implement SHA256
>  >   o MUST implement ECC256
>  > [ o MUST implement 3DES - directly inherited from 4880, like it or not]
>  >   o MUST implement AES128 [or just inherit the SHOULD from 4880??]
>  >
>  >   o SHOULD implement AES256-SHA512-521ECC
>  >   o MAY implement    AES256-SHA384-384ECC
>  >
>  >   o SHOULD try to match cipher strength with ECC strength, where
>  >     recipient key preferences allow.
>  >
>  > (then need to add wording in about restrictions required for if strict
>  > Suite B compliance is required.)
>  >
>
>
> David, I agree with this.
>
>  Assuming this is consensus, I will change section 11.1 to "MUST
>  implement curve with ID 1 and SHOULD implement curve with ID 3". Also in
>  section 11.1, I will change to "MUST implement SHA2-256 and should
>  implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST
>  for OpenPGP profile.

this sounds like what what we've got to so far, although I note
that this makes the [AES256-]SHA384-384ECC an *implicit* MAY
rather than *specifically* mentioning SHA384 and ECC384 as
MAYs.

So, should we *explicitly* mention them?

(also, an aside regarding repetition of a point I've previous made:
the (e.g.) keywrapping text in -pre6 only talks about AES; this
needs to be made more general, referring instead to keylengths.)


>  I will add a few sentences about Suite B and RFC4880 (in)compatibility.
>  The problems are very very similar to the issue of FIPS mode of
>  operation and RFC 4880.

yes

>  Regarding algorithm tupples, Section 12 already lists
>  AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations.

the -pre6 document specifically lists  P384-SHA384-AES192
in 12 (which, as per NIST, *are* the matching strengths), with
the "MAY use stronger" in the paragraph before the table, but
with the the AES256 (as per Suite B) in 11.2.2 before.

All these pieces *together* allow for our discussed
AES256-SHA384-384ECC combination, i.e. to support Suite B
and to "drop" AES192.


>  I think it is better to break tupples into 3 pieces and address them
>  independently.

Maybe it's because I haven't re-read the document as a whole
with all our changes in place, but I'm personally finding it a bit
hard to read our discussed cipher suggestions when they are
split up as they currently are.

Do you want to try producing a -pre7 so that we can see if we
think it (a) matches our growing consensus and, (b) says it in
a clear manner?

If it does then great, otherwise some section, paragraph and
topic re-ordering might be required.

> The choice of symmetric algorithm is governed by key
>  preferences of (multiple) recipients. We shouldn't disregard preference
>  list and prefer AES-256 (even for ECC keys).

4880 section 13.2 says this:

   An implementation MUST NOT use a symmetric algorithm that is not in
   the recipient's preference list.  When encrypting to more than one
   recipient, the implementation finds a suitable algorithm by taking
   the intersection of the preferences of the recipients.  Note that the
   MUST-implement algorithm, TripleDES, ensures that the intersection is
   not null.  *The implementation may use any mechanism to pick an
   algorithm in the intersection.*

I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC
applications.  So, our ECC document would have something like:

  Having obtained an intersection of symmetric algorithm preferences,
  implementations SHOULD attempt to match symmetric algorithm size
  with public key size.

[*Personally*, I'd like to continue:
  ", favouring longer lengths where possible."]

  The following table provides current equivalent recommendations
  (SP800-57). Note TripleDES is considered to have 112-bit security.

           Asymmetric  |  Hash  |  Symmetric  |  Elliptic
            key size   |  size  |   key size  |  curve key
           (RSA + D-H) |        |             |  size
           ------------+--------+--------------------------
              1024        160         80           160
              2048        224        112           224
              3072        256        128           256
              7680        384        192           384
             15360        512        256           521

[the columns should probably be in a "better" order, this was
just copied from 4800 with ECC then added on the end]


>  So section 11.1 tell
>  MUST/SHOULD for individual algorithms and section 12 gives SHOULD
>  recommendations regarding dependencies between algorithms.

Subject to my "clarity" point above, then OK, yes, I can see
this is how you are conveying this at present.


>  After above changes to section 11.1, the only missing correction there
>  is "SHOULD implement AES-256".

yup.