One more note (well, two):
i) What is "amended" FIPS 186-4? I do not know of such a thing (I only
know of [1] and [2], where only [1] has official status).
You wrote: I would presume that ECDSA in FIPS 186-5 draft and amended FIPS
186-4 are exactly equivalent. If not, that would be a fine footgun...
ii) the output of SHA-hash function family in FIPS 180-4 [3] is a bit string,
as are outputs of the SHA3-related functions in FIPS 202 (see Alg. 8 hereof for
the output of the sponge function and Section 2.3 for definition of trunc_s()
function, which operates on bit strings).
Ref: [1] FIPS Pub 186-4 Digital Signature Standard (July 2013)
[2] FIPS 186-5 - Digital Signature Standard (DSS) (draft, October 31,
2019)comments till January 29, 2020
[3] FIPS PUB 180-4 - Secure Hash Standard (Revision, August 6, 2015)
[4] FIPS Pub 202 - SHA-3 Standard - Permutation-Based Hash and Extendable
Output Functions (August 6, 2015)
On 2021-11-19 10:41 a.m., Ilari Liusvaara wrote:
On Sun, Nov 07, 2021 at 01:00:36PM -0500, Rene Struik wrote:
Hi Ben:
A friendly reminder of the reminder of the reminder. Is it really necessary
(or fair, for that matter) that a simple technical disposition email
exchange takes more than a half year, with me having to consistently pick up
dropped balls?
I was trying (months ago) to figure out how exactly the hash-as-integer
in ECDSA signatures is computed when using SHA-3/SHAKE* as hash
function. Summarizing how far I got:
If using FIPS 186-5 draft rules (it is just ordinary binary number
representation already truncated to correct length), one can use the
following algorithm:
* Bitreverse all octets.
* Read octets as big-endian integer.
* Shift integer right to remove excess bits, if any.
If using signhash-style ECDSA API, it probably internally does the last
two steps, leaving just the first one to caller.
However, the problem is that FIPS 186-5 draft is draft, and the current
definitive spec is FIPS 186-4. What happens if one uses FIPS 186-4
(AFAIK, it has been amended to allow SHA-3/SHAKE) rules. FIPS 186-4
itself specifies that:
* The hash as bit string is truncated if it is too long.
* The remainder is specified in X9.62.
The issue here is that what happens here depends on exact specifics of
X9.62 rules, and X9.62 is paywalled. There are some open documents that
have description of ECDSA, but that description might have been
"simplified" using invalid assumptions. So these descriptions are
suspect at best.
For example, SEC1 version 2.0 has an self-contained description that
does not agree with FIPS 186-5 draft. Where things diverge is FIPS 186-5
draft directly taking hash as bit string, whereas SEC1 takes it as octet
string and then converts to bit string. That would be fine for SHA-2,
but it is very much not fine for SHA-3 or SHAKE*.
I would presume that ECDSA in FIPS 186-5 draft and amended FIPS 186-4
are exactly equivalent. If not, that would be a fine footgun...
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
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
