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