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

"Scott Fluhrer (sfluhrer)" <> Thu, 13 December 2012 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B82CE21F8A9B for <>; Thu, 13 Dec 2012 07:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YfCka2uxtiyH for <>; Thu, 13 Dec 2012 07:57:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1444721F8A99 for <>; Thu, 13 Dec 2012 07:57:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3294; q=dns/txt; s=iport; t=1355414279; x=1356623879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J+NmaIMoRmmezwU1qRSE0seHXWgvLMdHxiykmNKiJ3k=; b=GqB8Px7UrMJCdZTwdQYTatShRIrzpxYmEOs9Iso/xbHY96hiAm2RtD93 nJVjPNTsGlF1Iq0+2e4MQq0pqD9X+LCSKZvnpNaFCeDvhnNLyzgYK+D/3 sknG40mMnOkQ1C18ka27rtdo9lHaZYyalOuApb9dIsjqNubfCO8qgFlQX c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIP6yVCtJXG+/2dsb2JhbABFvm4Wc4IeAQEBBDozDAwEAgEIEQQBAQsUCQcyFAkIAgQOBQiIC71WjFeDYmEDplGCc4Ii
X-IronPort-AV: E=Sophos;i="4.84,274,1355097600"; d="scan'208";a="152641660"
Received: from ([]) by with ESMTP; 13 Dec 2012 15:57:34 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qBDFvYe2004291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 15:57:34 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 09:57:33 -0600
From: "Scott Fluhrer (sfluhrer)" <>
To: Johannes Merkle <>
Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks
Thread-Index: AQHN1wZaPpZNcIh600ewXpvuWaXH0pgUSukAgAEvCfCAAXk8gP//62bg
Date: Thu, 13 Dec 2012 15:57:32 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <>, Dan Harkins <>
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2012 15:57:59 -0000

> -----Original Message-----
> From: Johannes Merkle []
> 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