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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
