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

Andrey Jivsov <> Mon, 07 January 2013 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29DD321F882E for <>; Mon, 7 Jan 2013 10:32:47 -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 M3gc0aUdRih2 for <>; Mon, 7 Jan 2013 10:32:46 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:24]) by (Postfix) with ESMTP id A99B221F882B for <>; Mon, 7 Jan 2013 10:32:46 -0800 (PST)
Received: from ([]) by with comcast id l4uZ1k0041vN32cA26YmXm; Mon, 07 Jan 2013 18:32:46 +0000
Received: from [] ([]) by with comcast id l6Yl1k00T2g33ZR8i6YllT; Mon, 07 Jan 2013 18:32:46 +0000
Message-ID: <>
Date: Mon, 07 Jan 2013 10:31:16 -0800
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Stephen Kent <>
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=1357583566; bh=TKh1XzvZdw0nTmyQSAGqswsEgzSzOTaP/P5yE+k1k6c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tLf/lWdl1E1dpECRQ1HBGo8bY7ikrZQDg15e6/Udh/ehLU5IShhk2oFutW9R4MN8q z/H3Ct4U2pXpEXip6cE/uIenqYJK+RFCrjoDN1wy1PjrzzYSFLaD0G67INu6qoa8Os Wh+0EZaqkAggcYZzegwamRqKB8lQtppPb4P4F11shO0c7UO7e7BrFtY8vo10nj5fmW IsuNgS7l+NKRdr7ahTmU9pEhUdIHPmuXnGIpEWXVZpeco4y6JE8vpLfVaE+IOxzvka otBq4hNhQGtJstrX6K3aeciUDRLubuGZKiNjrP55LWtf0J0c7CLDuR8wYPhWtuyArV jo8YLIZ3V74JA==
Cc: ipsec <>
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: Mon, 07 Jan 2013 18:32:47 -0000

On 01/07/2013 07:52 AM, Stephen Kent wrote:
> On 1/4/13 3:23 PM, Andrey Jivsov wrote:
>> ...
>> 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.
> Are you confident that this attempt at space efficiency is consistent
> with S/MIME processing rules?
> Or are you suggesting that S/MIME and other secure email standards
> become alg-specific to take
> advantage of this optimization?

If you are asking if my proposal is compatible with the current format 
that IETF standards use, which is by and large is SEC1, then, no, my 
proposal is not binary identical to the SEC1. The issue of this 
interoperability is discussed in the spec.

While I believe that my proposal, which is written for modp curves, is 
superior to (modp subset of) SEC1, I realize that adding an alternative 
compact representation / point compression to existing standards is an 
uphill battle. For existing standards that define some point compression 
I would only say that if one finds that the point compression is not 
actually used / configured in real-world implementations, please take a 
look at my proposal as it may be a format that will eventually find its 
way into the implementations if standardized (IPR issues is one such a 

For any new format / protocol / feature, RFC 6090 + should be a more 
natural path.

>> 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.
> Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs
> always contain just one key.
> So I'm puzzled by the phrase "Even for certificates that have one public
> key ..."

I agree that the statement was unclear. I was saying that because the 
certificates contain only one public key, the space saving is only 
size-of-the-curve+1 byte per certificate. Nonetheless, given that 
certificates need to be pre-processed and validated, and these results 
are often cached, the overhead of calculation of the 'y' is probably not