Thank you, Johannes, for your comments. I will integrate them in the
next revision.
I do agree that for online protocols like IKE and TLS the point
compression of the ephemeral ECDH is not that beneficial.
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.
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.
On 01/04/2013 04:10 AM, Johannes Merkle wrote:
Hi Andrey,
point compression has been deleted from the draft due to the strong objections
in this WG. The possibility to choose
from two distinct encodings was considered inappropriate complexity given the
limited benefit.
Generally, I think that your draft has its value, albeit probably not for IKE.
Some nits:
Line 256:
Recall that the x is an integer in the underlying finite field.
should be
Recall that the x is an element in the underlying finite field represented
by an integer.
^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^
Line 352:
When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves
should be
When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves
^^^^^^^ ^^^
Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the
private key in Section 4.2
Section 5:
First, key pairs must be generated as defined in Section 4.2 to allow
compact representation.
But, as you have pointed out in Section 3:
Some protocols, such as ECDH, don't depend on the exact value of
the y.
Thus, in these protocols, it does not matter, if the key is "compliant" or not.
This should be explained, not only in
Section 5 but also in the beginning of Section 4.2.
regards,
Johannes
Andrey Jivsov schrieb am 03.01.2013 08:07:
Sorry for bringing up this so late, but I just noticed the discussion about the
point compression in this thread.
I posted the "Compact representation of an elliptic curve point"
http://tools.ietf.org/html/draft-jivsov-ecc-compact
that I think is helpful as a generic definition of a compressed point.
I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
-03 moved away from the compressed
representation, but the preceding discussion is one of the reasons why I
created this draft. It's unfortunate that with
current state of ECC at IETF there is always an uncertainty/complexity such as
"do we use an uncompressed point or
compressed point; and there is IPR". There is also an issue of what's hashed
and how the {x,y} is encoded. In the end in
practice this means that there is no compression used.
I want to add as an alternative point of view that for new features or
protocols there is also a way to reduce
complexity by using only the compact point representation, such as in
http://tools.ietf.org/html/draft-jivsov-ecc-compact.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
