[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-02-21 05:12:40

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 sell product.

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 that's it.

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 it.

I think that the incremental cost to achieve Secret level of Suite-B is insignificant, given that an application has implemented Top Secret level.

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 all time.

This proposal offers the least choice of ECC parameters of any IETF standard.

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 downgrade "Secret".

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 lower profile.