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