Looking closer, all what we discuss here is related to ECDH, so the sign of a point is not important for the result.
In this case the compression can be a simple truncation to <x>, e.g. without the need to do tricks with the private key to make this an unambiguous representation of a point. This simple truncation works with existing software. I think that TLS should adopt the <x> format (without 02 or 03 prefix). Note that this truncation extends to the SEC1 compressed format: in this case we just drop the first byte. This truncation is highest-performance option and it's simplest too. On Tue, Oct 26, 2021 at 12:58 AM John Mattsson <john.matts...@ericsson.com> wrote: > There are several active documents also defining compact representation. > > > > After the discussion regarding HPKE there was a suggestion EDHOC should > define a compract format that could be reused by other protocols. That was > done in an Appendix. > > https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#page-67 > > > > Also as an outcome of the HPKE discussions Dan Harkins has written on > compact representation for HPKE submitted to CFRG. This also defines a a > general format than can be reused by other protocols. > > https://datatracker.ietf.org/doc/draft-harkins-cfrg-dnhpke/ > > > > > the support for 'regular' (SEC1) compressed curves is more widespread. > > > > What is support in this case? An implementation can just use one of the > values "02" and "03" or flip a coin. If you have support of 'regular' > (SEC1) compressed curves, then compact representation is trivial. > > > > Cheers, > > John > > > > *From: *TLS <tls-boun...@ietf.org> on behalf of Andrey Jivsov < > cry...@brainhub.org> > *Date: *Tuesday, 26 October 2021 at 07:15 > *To: *Carl Mehner <c...@cem.me> > *Cc: *IETF TLS <tls@ietf.org> > *Subject: *Re: [TLS] Point Compression > > Do we have evidence that "02 <x>" or "03 <x>" is more widespread than <x> > for NIST curves? I haven't seen "02 <x>" or "03 <x>" in deployed products > in TLS / X.509 at all. So, I feel that for TLS space the slate is clean > regarding compression. X25519 uses one coordinate, which is simiiar to > doing <x> for NIST curves... >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
