Re: ECC in OpenPGP proposal

David Crick wrote:
> On 3/4/08, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> 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?
>   
My thoughts on MAY were that since this spec is MAY in relation to 
RFC4880, the explicit MAYs on defined or otherwise referenced algorithms 
are redundant. If we define a curve and don't list it as SHOULD or MUST, 
I assumed that it follows that it is MAY.
Where do you see a benefit of explicit MAY? 384 ECC is defined in this 
spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in 
this spec.
Can using MAY once create questions as to why other combinations are not 
MAYs?
> (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.)
>   
You are right, there is a dependency on AES in this spec. It is 
currently required in AESWrap key wrapping method. I realize that you 
may have interpreted this differently. I prefer we fix AES with AESWrap 
method, and this is how the -pre6 is written. The argument about 
multiple recipients doesn't apply here, but relative strength does. I 
suppose that even embedded devices can use AES-256 as KEK for key 
wrapping and AES-128 for message encryption (or any other algorithm for 
latter) , because the performance of AESWrap is not an issue on up to 48 
bytes (the availability in hardware probably is). In any case, any of 3 
AES variants are allowed in current proposal for AESWrap, plus, we have 
AES-256 as SHOULD.
For example, http://www.ellipticsemi.com/products-clp-34.php shows 
hardware implementation, which is hardwired to AES 128 or 256.
(Just to be clear, nothing in this section applies to the choice of 
algorithm for symmetric message encryption key.)
> >  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.
>   
Yes. The main reason to keep 192 is interoperability.

> >  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.
>   
Yes, I will update the spec based on latest feedback.

> > 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.
>   
I note that this issue is orthogonal to this spec, i.e. it applies to 
RFC 4880 as well. However, if there is a consensus, we can recommend 
this. One justification for "why now" is, practically speaking, ECC 
allows balanced strength while RFC 4880 doesn't. However, I would try to 
stay within RFC4880.
The issue of tightening is similar to other restrictions I put in 
section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian 
suggested MDC/S2K to be MUST.
> [*Personally*, I'd like to continue:
>   ", favouring longer lengths where possible."]
>   
While we should not deprive implementations the allowed method to 
advertise prioritized preferences, I think we there is a room for 
improvement in "grey areas". For example,
* Two recipient keys have following ordered prefs.: {AES128, AES256} and 
{AES256, AES128}.
* RFC 4880 allows either of these sets to be the ordered intersection.

In this case we can "tighten" as you suggested.

Many of these issues are in the realm of key managing software. If user 
is adding single AES128 preference to ECDH 521, the software can warn her.
 
>   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.
>   
I will integrate feedback from everybody into the next revision. Thank you.