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

Andrey Jivsov <> Tue, 08 January 2013 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE0821F8578 for <>; Tue, 8 Jan 2013 11:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ribHggKBDiRa for <>; Tue, 8 Jan 2013 11:38:13 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:56]) by (Postfix) with ESMTP id 8B98921F8542 for <>; Tue, 8 Jan 2013 11:38:13 -0800 (PST)
Received: from ([]) by with comcast id lVuf1k0081bwxycA6XeDjb; Tue, 08 Jan 2013 19:38:13 +0000
Received: from [] ([]) by with comcast id lXeB1k00V2g33ZR8eXeCbL; Tue, 08 Jan 2013 19:38:13 +0000
Message-ID: <>
Date: Tue, 08 Jan 2013 11:35:17 -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=1357673893; bh=Rxi0upSCOPhbgWqV+v+A4UqkoHa2DUFDMbc17ZbRg04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ay3YO3mljExMhqG2NOvWA2bF+1cfC+ob+uAgoOJ2qMG9F8btOIyZUpEorHNJ1jcsh Zq7qz1s84ZrYv4++lGauhy1B0S3Ml4NyEC3N/nm10qyX0z1Ty7RtOyhJqDBPj7VadJ b9JKCIvw5EmOtYXqkq/FKcqsDpOqaNWOtfB7JmVMBwSIWdFQAo0Ksv6F/KrJsKAYOu uayHO6BEbhp/UfJgKi1NVZwd4OAdKENOmQGt2CkdEDJw7yJojZupJdMPOn+Cw3DYtF tZATT8WlgwEtWMjN6rSOIO6Ka9IbmTYFBKImy1ZumgDa6HcJp59KGIsuu3UV0EARjO dHDs7IdBcrxfA==
Cc: ipsec <>, Johannes Merkle <>
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: Tue, 08 Jan 2013 19:38:14 -0000

I believe that the compact representation of the point documented here is suitable for any 
IETF protocol. It doesn't expect changes of processing rules, that would 
be a non-starter.

For example, consider how it would work for IKE Section 7 tells that IKE KE uses x|y 
sequence. My proposal would change it to x.

The bring a question of "isn't there up to 1 bit of entropy present in 
y"? I prove in the spec that it's valued as zero, i.e. it doesn't add 
anything to the security. Regardless, of the answer to whether there is 
0 or 1 of entropy present in y, the ambiguity of y/-y must be resolved 
and the method I propose does so by a minor tweak to the key generation, 
to generate a "compliant" key ( As a matter of fact, no tweaks are 
needed for ECDH keys, only for ECDSA keys. ECDH keys are always 
"compliant" when only the x of the shared point is used. )

This means that the IKE initiators and responders generate their 
ephemeral keys in such a way that the simple dropping of the y is what 
constitutes the compact representation.

This works the same way for SMIME with ECDH. Sender is free to generate 
a "compliant" ephemeral ECDH and the rest of processing rules are 
identical to current SMIME with point compression method.

BTW, I believe that a crypto software should always generate only 
"compliant" ECC keys, because there is no loss of security in doing so. 
Then the compact representation is worry free and is never conditioned 
on the type of the key.

On 01/08/2013 08:52 AM, Stephen Kent wrote:
> Folks,
> I think my initial concern has been misunderstood, or maybe I
> misunderstood the
> purported benefits of the proposed mechanism.
> When I asked about compatibility with existing S/MIME specs, I was not
> referring to
> details of how the EC public key is represented in  a cert, per se.
> Andrey's message on 1/4 said:
> "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. *
> My question was whether this technique, in bold above, is compatible
> with the current, normal
> processing for S/MINE, or whether it would require S/MIME to operate
> differently (at the originator
> or at any recipient) in order to reduce the overhead in the fashion
> alluded to above.
> I don;t think that question has been answered.
> Steve