Re: [IPsec] New draft on IKE Diffie-Hellman checks

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: Johannes Merkle [mailto:[e-mail]]
> Sent: Thursday, December 13, 2012 5:41 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: Dan Harkins; Yaron Sheffer; IPsecme WG
> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
> 
> 
> > I'm positing an audience of people who know little about elliptic curves;
> they have no idea about what a cofactor or a Sophie-Germain prime is.  All
> they're interested in is trying to implement this protocol in a secure
> manner, and want to dig into the mathematical details as little as possible.
> 
> Why not keeping the main document general and giving details for
> registered groups in an appendix?

Hmmmm, I like that suggestion.

> 
> 
> > The reason I put the group numbers in the titles is to make it easier for an
> implementer to decide, for a specific group, which section is appropriate.
> Perhaps another approach for achieving that goal would be better.
> 
> The mapping between the registered groups and the individual subsections
> should be given in the appendix.
> 
> 
> >>            hQ != point-at-infinity
> >
> > This is a cheap check (if h=2, I believe that's just a check that a coordinate
> != 0, and as you say below, it's even cheaper if h=1).  However, is there a
> specific attack that is possible if you don't do the check?  If you're worried
> about someone modifying the DH public value with this value, IKE already
> has protections against that in place.  If you're worried about someone
> learning the value of (e mod h) (where e is the private ECDH multiplier), this
> check doesn't prevent that.
> 
> You are right, this is exactly what Daniel has pointed out. Unfortunately, in
> case of a non-trivial cofactor, the check n*P != 0 necessary to prevent an
> attacker from learning (e mod h) is not cheap at all. In that case, the
> suggestion of Hugo applies as well, i.e. it is better to recommend not to
> reuse DH keys for EC groups with non-trivial cofactor.

Here's what I'm wrestling with; every curve that we currently support (and, in fact, every prime curve I've heard anyone suggest) has h=1 (having h>1 makes the discrete log problem be a factor of sqrt(h) easier, for no benefit that I can see); hence, this cofactor test is moot.  So, do we complicate our description (at least, of the prime curve section) with a test that never really applies?

Now, if we do have a section covering even characteristic curves, those have h>1 (the math pretty much forces that), and so a discussion there wouldn't be entirely out of place.  On the other hand, there are standardized ways of defining the ECDH operation so that the cofactor doesn't cause any leakage ("ECC CDH", where the shared secret really is hxyG); if the group is defined using that primitive, such a cofactor test beforehand is unneeded.  Will such a group use such a modified DH operation?  Well, given that no such groups are currently defined, we can't say.

My opinion: in the prime curve section, there's no reason to mention a cofactor; and that it's premature to put in an even characteristic curve section.

> 
> --
> Johannes