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

"Dan Harkins" <dharkins@lounge.org> Tue, 11 December 2012 22:01 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EBF11E80A6 for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 14:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.922
X-Spam-Level:
X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtOpzVSA56FN for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 14:01:36 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD021F853B for <ipsec@ietf.org>; Tue, 11 Dec 2012 14:01:36 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6EF2F10224008; Tue, 11 Dec 2012 14:01:35 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Dec 2012 14:01:35 -0800 (PST)
Message-ID: <a83fc639aa53bc1b6bb66406e88ade1c.squirrel@www.trepanning.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net>
References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <c2cc7c6b1feed9c2cec2ce5d5adcfbf1.squirrel@www.trepanning.net> <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net>
Date: Tue, 11 Dec 2012 14:01:35 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Dan Brown <dbrown@certicom.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IPsecme WG <ipsec@ietf.org>, 'Dan Harkins' <dharkins@lounge.org>
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 22:01:36 -0000

On Tue, December 11, 2012 1:36 pm, Dan Brown wrote:
>
>> -----Original Message-----
>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
>> Of Dan Harkins
>> Sent: Tuesday, December 11, 2012 4:32 PM
>> To: Dan Harkins
>> Cc: IPsecme WG
>> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
>>
>>
>>   I made a mistake below. Thanks to Dan Brown for pointing it out.
>>
>> On Tue, December 11, 2012 10:06 am, Dan Harkins wrote:
>> [snip]
>> >   - I think it should be mentioned that elliptic curve groups
>> >      have a co-factor, h, and if h > 1 that a further check is
>> >      also required, namely, if the x- and y-coordinates define
>> >      a point Q then ensure that:
>> >
>> >            hQ = point-at-infinity
>> >
>> >      Add this check to both 2.3 and 2.4. Of course if h=1 then this
>> >      check can be skipped.
>>
>>   The check should be hQ != point-at-infinity. An equivalent check
>> could be nQ = point-at-infinity where n is the order of the group
>> formed by the generator, G.
>>
> [DB] Well, the hQ != infinity check is insufficient for security, and not
> equivalent to ensuring that nQ=infinity.
>
> Dan, sorry, I did not explain these details in my response to you.

  That's interesting. Your paper "Validating EC Public Keys" (Antipa,
Brown, Menezes, Struik and Vanstone) says in section 3 that the
steps to validate an EC public key, W=(xw, yw), are:

  1. W != infinity
  2. xw and yw are properly represented elements of the finite field
  3. W satisfies the defining equation of the curve; and
  4. nW = infinity

It then says that "if h=1, then condition 4 is implied by the other
three conditions. In some protocols the check that nW = infinity may
either be embedded in the protocol computations or replaced by the
check that hW != infinity."

  Can you explain why hQ != infinity is insufficient and not equivalent
to nQ = infinity?

  thanks and best regards,

  Dan.