Re: [COSE] draft-ietf-lwig-curve-representations-13

[Rene Struik <[e-mail]>]

Hi Ilari:

I do not understand your posting, which is full of hearsay and 
ill-defined terms, such as "odd way", "usually", "have not tested this" 
(which are subjective terms). Can we please stick to facts?

ECDSA has been introduced in 1999 [1]. The specification of ECDSA25519 
[2] and that of ECDSA448 [3] uses the description in FIPS Pub 186-4, 
which is unambiguous.

If you nevertheless believe there are ambiguities in the specification, 
please point those out succinctly and in a technical matter, with 
detailed reference to the alleged substep where this "mishap" occurs.

Best regards, Rene

Ref:
[1] Don Johnson, Alfred Menezes, "The Elliptic Curve Digital Signature 
Algorithm (ECDSA)", CACR Corr 99-34.
[2] 
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19#section-4.3 

[3] 
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19#section-4.4



On 2021-01-14 8:12 a.m., Ilari Liusvaara wrote:
> On Wed, Jan 13, 2021 at 09:26:15AM -0500, Rene Struik wrote:
>> Hi Goran, John:
>>
>> Please let me know if my response to the COSE mailing list (Dec 19th) works
>> for you. If you have comments, please suggest constructive improvements.
>>
>> I really would like to get closure on this.
>>
>> I value your feedback, even though you brought up your points more than two
>> months after the IETF Last-Call. I hope we can move forward without undue
>> delays.
>>
>> Thanks for your help, Rene
>>
>> On 2020-12-19 11:01 a.m., Rene Struik wrote:
>>> Dear John:
>>>
>>> Based on your review and other feedback received, I slightly updated the
>>> draft and posted the latest revision as [1].
>>>
>>> Your review below (of Nov 6, 2020) seems to bring up three topics, viz.:
>>> (1) definition of Wei25519 and Wei448 vs. verbiage in NIST docs; (2)
>>> need for iana registrations for ECDSA25519 and ECDSA448; (3) need for
>>> iana registrations ECDH25519 and ECDH448.
>>>
>>> Please find below some feedback.
>>>
>>> General feedback:
>>>
>>> Please bear in mind that the specifications of ECDSA25519 and ECDH25519
>>> in the lwig curve document aim to yield schemes that are strictly
>>> NIST-compliant (i.e., these would allow FIPS 140-2 accreditation if the
>>> curves would be in the "NIST recommended" set). See also Note 2 of
>>> Section 4.1 of [1]. A similar remark applies to ECDSA448 and ECDH448.
> I think the spec should call out the odd way hash truncation in ECDSA
> works with these curves, as it is unlikely implementations have
> encountered that kind of special case before.
>
> As far as I understand (z is the integer value representing the message
> in both signing and verification... I have not actually tested these, so
> there might be bugs):
>
> 1) Wei25519:
>
> C = 31;
> if len(hash) > C:
>    z = int.from_bytes(hash[:C],byteorder="big");
>    y = hash[C];
>    if is_sha2(hashfunc):
>      z += y // 8 << 8*C;
>    elif is_sha3_or_shake(hashfunc):
>      z += y % 32 << 8*C;
>    else:
>      raise ValueError("Unsupported hash");
> else:
>      z = int.from_bytes(hash,byteorder="big");
>
> 2) Wei448:
>
> C = 55;
> if len(hash) > C:
>    z = int.from_bytes(hash[:C],byteorder="big");
>    y = hash[C];
>    if is_sha2(hashfunc):
>      z += y // 4 << 8*C;
>    elif is_sha3_or_shake(hashfunc):
>      z += y % 64 << 8*C;
>    else:
>      raise ValueError("Unsupported hash");
> else:
>      z = int.from_bytes(hash,byteorder="big");
>
> Where is_sha2 and is_sha3_or_shake are predicates for the hash function
> that check if the hash function used is one from SHA-2 or from
> SHA-3/SHAKE respectively. The dependence on these predicates cause major
> issues with traditional signhash-style ECDSA implementations.
>
>
> If the above is wrong (beyond just bugs or typos), it would be
> especially necressary to write how the case is handled, as even trying
> to carefully work out how it works leads to wrong result.
>
>
> (For comparision, here is what truncation looks for P-256:
>
> if len(hash) > 32: hash = hash[:32];
> z = int.from_bytes(hash,byteorder="big");
>
>
> There is no reference to hash function used.
> )
>
>
>>> Detailed feedback:
>>>
>>> (2) Need for iana registrations for ECDSA25519 and ECDSA448.
>>>
>>> ECDSA is determined by an instantiation of hash function, curves, and
>>> representation conventions for inputs and outputs (i.e., message
>>> representation, curve point representation, and signature
>>> representation).
>>> a) ECDSA448 uses SHAKE256 under the hood, which is currently not defined
>>> with COSE. Hence, my request to register ECDSA w/ SHAKE256 and Wei448 as
>>> "ECDSA448".
>>> b) ECSA25519 uses SHA256 and Wei25519 under the hood. I thought to
>>> request to register "ECDSA25519" since this would allow referencing the
>>> quite careful write-up (Section 4.3), including bit/byte ordering,
>>> checks, and nondeterministic behavior (and, thereby, keeping this
>>> concise). Please note that this is very similar to the COSE IANA
>>> registry for "ES256k1" (ECDSA w/ SHA256 and Bitcoin curve secp256k1).
> This is not how ECDSA is usually used (and this goes to a lot of other
> things besides COSE and JOSE, e.g. to TLSv1.2 and PKIX). Usually in ECDSA,
> the algorithm determines the hash function, and key determines the curve.
> This would presumably still hold if doing agility-by-key (not that either
> COSE nor JOSE have the necressary means for that).
>
> IMO, ES256k1 was a mistake. That should have had alg ES256 and
> crv secp256k1.
>
> (TLSv1.3 mixes hash and curve, but seemingly only to simplify
> negotiation, which is not applicable here, since COSE/JOSE are not
> interactive. Many implementations probably do not check that the curve
> is correct. Mine certainly does not.)
>
>>> (3) Need for iana registrations ECDH25519 and ECDH448.
>>>
>>> ECDH25519 and ECDH448 are co-factor Diffie-Hellman key establishment
>>> schemes and can, therefore, not be based on (cofactorless)
>>> Diffie-Hellman, as defined in RFC 8152. (Please note that there is no
>>> difference for the NIST curves, which all of co-factor h=1, but in our
>>> case one has h=8 and h=4, respectively). Here, one should note that the
>>> ECDH25519 and ECDH448 write-ups (Section 4.1 and 4.3) quite carefully
>>> cross-reference co-factor ECDH in a NIST-compliant way. Apart from the
>>> co-factor ECDH vs. ECDH issue and objective to comply with all strict
>>> NIST validation checks, the objective was also to make sure that
>>> ECDH25519 and ECDH448 can be used in settings where either or both
>>> parties uses ephemeral keys (which is more flexible than what RFC 8152
>>> allows).  Hence, the request to register "ECDH25519" and "ECDH448", to
>>> make sure this covers the intent of these schemes accurately and with
>>> precise description.
> COSE does not just have ECDH, it has many different variants of ECDH.
> It would probably be easier to define cofactor ECDH by performing the
> cofactor multiplication (which seems to be the only difference between
> cofactor and non-cofactor ECDH) in output shared secret conversion.
> Otherwise one would need at least 8 new algorithms (SS/ES times KW/KDF
> times 128/256).
>
>
>
> -Ilari


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]