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.
http://iang.org/ssl/h1_the_one_true_cipher_suite.html

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.

> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

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.

iang