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.