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

Dan Brown <> Tue, 11 December 2012 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78E021F0CB1 for <>; Tue, 11 Dec 2012 14:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.903
X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WbKUOKlSfmwq for <>; Tue, 11 Dec 2012 14:29:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B88C91F0CAF for <>; Tue, 11 Dec 2012 14:29:02 -0800 (PST)
X-AuditID: 0a41282f-b7fea6d000001d56-c5-50c7b3a0ebb9
Received: from ( []) by (SBG) with SMTP id 15.7F.07510.0A3B7C05; Tue, 11 Dec 2012 16:28:48 -0600 (CST)
Received: from ([fe80::fcd6:cc6c:9e0b:25bc]) by ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 17:28:48 -0500
From: Dan Brown <>
To: 'Dan Harkins' <>
Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks
Thread-Index: AQHN1wZilu/9uGwwRUmtYsZlChLDnZgUOiUAgAA5pgD//6x6sIAAW6uA//+t3gA=
Date: Tue, 11 Dec 2012 22:28:47 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, 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
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXC5bjwgu6CzccDDKbc07BY+u8Li8X+LS/Y HJg8liz5yeTxbPdLlgCmqAZGm6TEkrLgzPQ8fTubxLy8/JLEklSFlNTiZFsln9T0xByFgKLM ssTkSgWXzOLknMTM3NQiJYXMFFslEyWFgpzE5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZp5Ca l5yfkpmXbqvkGeyva2FhaqlrqGSnm9DJk7H34Eemgsn8Fcs65rA1MD7k7mLk5JAQMJFou3mY EcIWk7hwbz1bFyMXh5DAKkaJXY8aWCGcrYwSb560s4FUsQmoStw/eo65i5GDQ0RAXWLL91iQ MLOAvMTmL7vASoQFrCXW/9oPNlREwEZi3op7rBDlfhJbz1aBhFmApjQ0PWcBsXkF3CR2Tz/N DLFqI5PE23m/WEESnALeEuu3zAabySggK7H77HUmiF3iEreezGeCOFpAYsme88wQtqjEy8f/ WCFsRYnVr26xQdTrSCzY/QnK1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV o2BuRrGBmUFyXrJeUWauXl5qySZGcJrQ0N/B+Pa9xSFGAQ5GJR7e+GPHAoRYE8uKK3MPMUpw MCuJ8BquOh4gxJuSWFmVWpQfX1Sak1p8iNEVGCwTmaW4k/OBKSyvJN7YwAA3R0mcV5n5YICQ QDowKWWnphakFsHMYeLgBNnDJSVSDEwtqUWJpSUZ8aAEGF8MTIFSDYyT/KfPbmr4k/7ywdLe kGtdc4K3JfV3OvEIJL/IePFdbynf7qVPFvrru1znYl82Y55Ju0DELzmj1F5eC+HDK0NaDAV/ H96Ucz9b5WDpi+Vtb7anLi2SZrr0QOnz+ZAL04LajblPPVp7eGGIU1udK5fqpLrlNitsWPMf n70c9MHaoGHCmk1P5kxQYinOSDTUYi4qTgQA4WC0EVQDAAA=
Cc: IPsecme WG <>
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: Tue, 11 Dec 2012 22:29:03 -0000

Hmm, I think this may be getting too far off-topic for IPSec, since IKE mostly uses ephemeral keys ...

> -----Original Message-----
> From: Dan Harkins []
> Sent: Tuesday, December 11, 2012 5:02 PM
>   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."

[DB] Sorry about that mistake in the paper.  That paper was mostly about skipping the check number 3, not step 4.

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

[DB] I should first correct myself when I said "insufficient for security".  This only really applies for very large h, which would be a very unusual case. 

Now suppose that G has order n and H has order h.  Then Q=G+H has order hn, not h.  In particular, it would pass the simpler test of hQ != inf.  

Suppose s is a static private key s, and P = sG is the corresponding public key.  

The shared secret is s applied to Q is Z = sQ = sG + sH = P + sH.  Therefore, Z is confined to a small set, and can leak information about s, which is the main security problem.

So, log_2(h) bits of the private key can be leaked.  For most curves, h is small, and this is not too big a deal.  

Anyway, the hQ != infinity test is not equivalent to the nQ = infinity test. 

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.