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

Stephen Kent <> Tue, 08 January 2013 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D660B11E80D5 for <>; Tue, 8 Jan 2013 08:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.999
X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c1RO3roC3-CN for <>; Tue, 8 Jan 2013 08:52:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0B14C11E8097 for <>; Tue, 8 Jan 2013 08:52:13 -0800 (PST)
Received: from ([]:50306) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1TscPK-0004Ee-Pu; Tue, 08 Jan 2013 11:52:10 -0500
Message-ID: <>
Date: Tue, 08 Jan 2013 11:52:09 -0500
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Johannes Merkle <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020201080301080003010606"
Cc: ipsec <>, Andrey Jivsov <>
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 16:52:14 -0000


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.