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: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
