ietf-openpgp
[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-03-05 05:23:59

On 3/5/08, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> wrote:
 > 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?

 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.

readability and understandability (of our intentions/recommendations)

 Can using MAY once create questions as to why other combinations are not
 MAYs?

possibly, but the reverse it more true: it draws attention to the fact
that *this* is something you should *consider*.

 > (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.)

re the just to be clear, I think this is what has partly muddied the water.

But / so (for my sanity ;)), could you please explain how one uses
a 3DES session key with ECC D-H?

 >> 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.

great.  Again, I'd like to see "clear" wording in the ECC doc to
indicate this; otherwise implementers may either miss this fact
or be left scratching their heads wondering how to handle it.

 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]

just for *me* to make clear :), I was suggesting we add this table into
the spec, just as 4880 does in its.  As you've said, this key management
issue becomes more of an issue as we now have the ability (or the
requirement, with Suite B) to match lengths.   Again, including this,
but spelled out, makes it a lot clearer.

I will integrate feedback from everybody into the next revision.
Thank you.

I think the ECC spec fits somewhere between 4880 and the Camellia
draft in terms of complexity of detail that is needed to be conveyed.

The Camellia draft is wonderfully short, since all it needs to say is
"this is an alternative cipher you can use.  in limited, certain situations
using Camellia can cause interoperability issues."

The ECC doc, however, has to spell out why and when using this new
public key system would be beneficial, possible ways of using it, the
most suitable ways of using it, and some more complex interoperability
issues.

I therefore feel we need to veer towards using *more* wording to justify
and explain usage of OpenPGP-ECC, rather than (necessarily) aiming
for the "less is more" approach that may be more preferable in general.