Re: ECC in OpenPGP proposal
Andrey Jivsov wrote:
Hello Ian, thank you for your comments.
Thanks for response. I have not responded in detail to all
your responses, we might be better off both seeing how the
rest of the group chimes in. Instead I've just amplified my
points where there was some divergence.
On background, when it comes to agility, I am a little bit
of a nazi. To me, choice is bad, nasty, evil. This is
because the choice does no good for the user, and lots and
lots of bad.
A few points below:
... "SHOULD support ECDH"
what is the point of not supporting ECDH? I recommend MUST.
I can support this.
However, please note that the signature has more weight by being a tool
of certifications, i.e. self-signatures depends on it. Without support
for ECDSA we cannot have functional EC keys, while we can have sign-only
keys without ECDH. It is possible to have sign+encrypt keys with ECDSA
top key and modp ElGamal DH.
Is your argument here that it is possible to do
signature-only applications with just ECDSA? So this opens
a window for a simplified implementation?
I would not be in favour of such an optimisation for the
simple reason that signature-only applications are not
common nor popular (nor well built IMHO). We are here to do
encryption. Signature-only concepts are something that
people talked about and failed to make good on the talk.
So I see this as a throw-back to the 1990s and DoJ ideas
about everyone having a digital signature and the world
being a better place and many other blind alleys. Didn't
happen, not useful.
Also note that ECDH brings with it the need to implement KDF and key
wrapping methods, because there is no ElGamal alternative in ECC field.
ECDSA should be easier to implement than ECDH.
OK, so there is more work if it is a MUST. To summarise, we
are here for the encryption. Digsigs are the option, not
the other way around. Therefore I recommend it as a 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.
This is to continue good tradition of algorithm agility in OpenPGP.
Ouch :) That tradition was born of a bunch of hackers and a
bunch of cryptographers who sat around and hacked and drank
wine and promised the world that it would be better. I
know, I was one of them.
OpenPGP these days is more a business area. People
implement OpenPGP not because it is sexy and they like wine
but because it solves problems for users and can help to
In business we do not want "agility". What we want to give
our users is a product that boots up and runs, securely, out
of the box. There is only one mode, and it is secure.
There is no place for agility in the world of business.
Agility never solved anything, I posit (a debate over wine,
ever there was one), and it sure created a lot of problems.
If there was a chance to to do it all again, I would (and
do) propose this as a rule: one true cipher suite, and
OK, read that, thanks. I suggest only one profile is
needed: "Top Secret". (I would do it as your ID 3.)
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
I think that the incremental cost to achieve Secret level of Suite-B is
insignificant, given that an application has implemented Top Secret
The incremental cost of "Top Secret" instead of "Secret" is
truly insignificant, yes, and the same in reverse.
My point is that the cost of two profiles over one profile
is huge. And I'm not talking about the implementors but the
users. Implement one "Top Secret" profile and be done with it.
Say that OpenPGP Suite-B is rated for all traffic, and save
the users a headache, for every message they must send, for
This proposal offers the least choice of ECC parameters of any IETF
I like it better for that :) The IETF has not been
particularly successful at crypto, so I don't mind drifting
a long way from their views...
At present the only MUST for OpenPGP are curves ID 1 and 2. It also says
that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These
are the curves/hashed approved by Suite-B. I can accepts that we reduce
the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B
"Secret" level and drop "Top Secret".
No, I'd suggest the reverse: "Top Secret" and drop or
If you must implement multiple profiles, then "Top Secret"
should be the MUST, and the lower one MAY. No point in
encouraging people to add agility, although there is a
potential market for the mobile phone people to implement a