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:
http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt
Unless you read this on a text terminal, here is the document in
alternative formats that offer cross-references as navigation links:
http://brainhub.googlepages.com/pgp
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.
=====