[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-02-20 03:50:52

Hi all,

Some comments. Caveat: I wouldn't know an EC if someone hit me over the head with it...

Big comment:  far too much variability, for little gain.

Andrey Jivsov wrote:

Hello OpenPGP list,

as Hal Finney had mentioned earlier, here is the draft:

Unless you read this on a text terminal, here is the document in alternative formats that offer cross-references as navigation links:

Why do we need ECC? The main reason is better alignment with the strength of symmetric key. Given that US government has chosen ECC in favor of modp for larger key sizes, this proposal is carefully written to comply with NSA Suite-B.

I think it is sufficient to state that you want a Suite-B compatible profile.

4.  ... "SHOULD support ECDH"

what is the point of not supporting ECDH?  I recommend MUST.


6. ... "the KDF hash function MAY be any hash function defined in [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used."

What is the point in permitting alternatives? If there is a good reason, I would prefer to see them enumerated for better understanding and for certainty.

I especially don't like "or its successor."

I ask ... without expecting to understanding the answer ... why it is that it is useful or necessary to permit any variability in the KDF?


11.2 I don't think it makes sense for OpenPGP WG to suggest that it knows what "Secret" and "Top Secret" means, nor that it can "achieve" this. The normative place for that is NSA. If some guidance of intentions is useful, it should be in the sense of a comment. "This profile is intended to be compatible with Suite B." If the NSA can be convinced to make a statement as to what works for them, include that too.


11.2 I don't see any point in providing both Secret and Top Secret? This seems like a way to create comaptibility problems for zero payoff. I suggest the full Top Secret as the only profile, and that's it.


11. Indeed, what is the point in allowing people to fiddle around with different curves, KDFs, and hashes? Nobody has ever cracked any of them, or nobody that we care about (which excludes the NSA, perversely). Set one and leave it as that.

This "profile" proposes 2 different public key algorithms, 3 different curves (plus future ones), 3 different hashes (plus future ones), 3 different AES strengths, MDC on or off, It/Salt as a SHOULD.

I suggest you would half the entire workload by reducing all above choices to 1 MUST, and reduce the compatibility problems to about a tenth.

It would then have a good chance of being a really useful profile. To business folks who don't care for the tea-room discussion about key lengths and rights to be compatible but uncommunicative...


12. "MDC SHOULD be used when symmetrical encryption key is protected by ECDH."

Is there any good reason to permit it to be dropped? Remove a compatibility complaint, make it a MUST?

Iterated and Salted S2K ... Ditto.