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

[Andrey Jivsov <[e-mail]>]

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 
concern).

For any new format / protocol / feature, RFC 6090 + 
http://tools.ietf.org/html/draft-jivsov-ecc-compact 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 
material.