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

[Andrey Jivsov <[e-mail]>]

I believe that the compact representation of the point documented here 
http://tools.ietf.org/html/draft-jivsov-ecc-compact 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 
http://tools.ietf.org/html/rfc4753. 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