Re: [TLS] Point Compression

[Andrey Jivsov]

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 , 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  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 
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  on behalf of Andrey Jivsov <
> cry...@brainhub.org>
> *Date: *Tuesday, 26 October 2021 at 07:15
> *To: *Carl Mehner 
> *Cc: *IETF TLS 
> *Subject: *Re: [TLS] Point Compression
>
> Do we have evidence that "02 " or "03 " is more widespread than 
> for NIST curves? I haven't seen "02 " or "03 " 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  for NIST curves...
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Point Compression

[Carl Mehner]

I uploaded a draft for the IANA assignments for compressed code points for
the NIST curves:
https://datatracker.ietf.org/doc/draft-cem-compressed-curves/
In it, I elected to not pursue the format to encode the types of keys
specified in draft-jivsov-ecc-compact
, mostly
because the support for 'regular' (SEC1) compressed curves is more
widespread. However, I'm not against using the method described by Andrey
if we want to shave off one more byte and require software updates to
handle the different format required.

ekr, (seeking advice for next steps): do you think this would fit better as
a footnote in the cTLS update presentation at ietf112 or do you think it
would need extra discussion?

-carl
On Fri, Jul 30, 2021 at 3:00 PM Andrey Jivsov  wrote:

> I propose a method to compress NIST curves as defined in
> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html
>
> Its main benefit is that the compressed point fits into field size / group
> order size. There is no additional byte needed.
> 
> On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner  wrote:
>
>> As requested during ekr's presentation
>> , I will volunteer to write up a
>> draft for defining new "supported groups" for compressed NIST curves. I
>> didn't see/hear any objections during the tls-wg meeting, but thought
>> I should probably confirm on the list before I got too far along in writing
>> it...
>>
>> -carl
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Point Compression

[Andrey Jivsov]

I propose a method to compress NIST curves as defined in
https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html

Its main benefit is that the compressed point fits into field size / group
order size. There is no additional byte needed.

This encoding is enabled by by modifying key generation. If key generation
code can be changed, the adjustment is one bignum subtraction. If key
generation is a black box, e.g. as if it is done by an HSM, we generate
another key pair until conditions are met.

On average, adjustment is needed every second key generation.

No adjustment is needed for ECDH.

The method is solely based on published books and research papers from the
past century.

I hope this helps.

On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner  wrote:

> As requested during ekr's presentation
> , I will volunteer to write up a
> draft for defining new "supported groups" for compressed NIST curves. I
> didn't see/hear any objections during the tls-wg meeting, but thought
> I should probably confirm on the list before I got too far along in writing
> it...
>
> -carl
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Point Compression

[Carl Mehner]

As requested during ekr's presentation ,
I will volunteer to write up a draft for defining new "supported groups"
for compressed NIST curves. I didn't see/hear any objections during the
tls-wg meeting, but thought I should probably confirm on the list before I
got too far along in writing it...

-carl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls