Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Andrey Jivsov <> Fri, 04 January 2013 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBD4D21F8853 for <>; Fri, 4 Jan 2013 12:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 96XxUCI9eUTX for <>; Fri, 4 Jan 2013 12:23:44 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:44:76:96:27:211]) by (Postfix) with ESMTP id C54BC21F8846 for <>; Fri, 4 Jan 2013 12:23:44 -0800 (PST)
Received: from ([]) by with comcast id jwLA1k0040cQ2SLABwPk2l; Fri, 04 Jan 2013 20:23:44 +0000
Received: from [] ([]) by with comcast id jwPj1k0052g33ZR8WwPjBz; Fri, 04 Jan 2013 20:23:44 +0000
Message-ID: <>
Date: Fri, 04 Jan 2013 12:23:43 -0800
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Johannes Merkle <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1357331024; bh=/Swz7ng/iAGUhNZJ0z4inWyO2IlumRBBs2zOBrWjcDA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e1aqrVD11fQB+DiT8kqLvIaIR5WHKfVTQI9JOlLEuG/tn4RKGyAs5pM+GEpNSks+L /WceOBeRltklRVZOUIVf0y8IiS7S3LwvHYO3tbuovbVRpO9H8axdjL64oSq1dqJb/G x2PjSMcpItGCwfpTdbyAG3V7TaYEE0dSdWjWGiyKXOOA4+N4kcNIEFhfGavaLYC9lT MPkYjgXoV4LmYi4WwHeT3K3mBNU+CfEWZlECsGLT9gz23CT2Zr99qVSPNRgumEVema tWsvRBU2OegVbkCTGrMW0ZuokroHGK48qHjH9eXGQ2+lZM0HI/xM939sXm/Oki9DrC 0BV1n5h/nwb1A==
X-Mailman-Approved-At: Sat, 05 Jan 2013 08:32:53 -0800
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
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: Fri, 04 Jan 2013 20:23:48 -0000

Thank you, Johannes, for your comments. I will integrate them in the 
next revision.

I do agree that for online protocols like IKE and TLS the point 
compression of the ephemeral ECDH is not that beneficial.

Point compression is more beneficial for storage security for reasons of 
performance and storage efficiency. For storage efficiency side: when 
there are multiple recipients per message, each associated with one 
ECDH-related field, it's possible for ECDH-specific payload to get 
arbitrary large for a fixed short message. For the performance argument: 
if the message was encrypted to N recipients, to decode it only one 
recipient will be used, and thus the calculation of 'y' is done once but 
the space is saved for N.

Even for certificates that have one public key there is some benefit, 
given that the certificates are pre-precessed for chain validation and 
are often cached.

On 01/04/2013 04:10 AM, Johannes Merkle wrote:
> Hi Andrey,
> point compression has been deleted from the draft due to the strong objections in this WG. The possibility to choose
> from two distinct encodings was considered inappropriate complexity given the limited benefit.
> Generally, I think that your draft has its value, albeit probably not for IKE.
> Some nits:
> Line 256:
>     Recall that the x is an integer in the underlying finite field.
> should be
>     Recall that the x is an element in the underlying finite field represented by an integer.
>                             ^^^^^^^                                ^^^^^^^^^^^^^^^^^^^^^^^^^
> Line 352:
>     When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves
> should be
>     When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves
>              ^^^^^^^                             ^^^
> Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the private key in Section 4.2
> Section 5:
>     First, key pairs must be generated as defined in Section 4.2 to allow
>     compact representation.
> But, as you have pointed out in Section 3:
>     Some protocols, such as ECDH, don't depend on the exact value of
>     the y.
> Thus, in these protocols, it does not matter, if the key is "compliant" or not. This should be explained, not only in
> Section 5 but also in the beginning of Section 4.2.
> regards,
> Johannes
> Andrey Jivsov schrieb am 03.01.2013 08:07:
>> Sorry for bringing up this so late, but I just noticed the discussion about the point compression in this thread.
>> I posted the "Compact representation of an elliptic curve point"
>> that I think is helpful as a generic definition of a compressed point.
>> I know that -03 moved away from the compressed
>> representation, but the preceding discussion is one of the reasons why I created this draft. It's unfortunate that with
>> current state of ECC at IETF there is always an uncertainty/complexity such as "do we use an uncompressed point or
>> compressed point; and there is IPR". There is also an issue of what's hashed and how the {x,y} is encoded. In the end in
>> practice this means that there is no compression used.
>> I want to add as an alternative point of view that for new features or protocols there is also a way to reduce
>> complexity by using only the compact point representation, such as in
>> _______________________________________________
>> IPsec mailing list