FIPS186-5 SIGVER, test vector incorrect oid for SHA3 digests

[mwcw]

Hi,

Vector Set: 1545230

{
        "tgId": 1,
        "sigType": "pkcs1v1.5",
        "modulo": 2048,
        "hashAlg": "SHA3-224",
        "n": "CAF7BAF3C0281B02F261E3884D3BCE535C0E46704CE0D74219650EB64229F023D93690B22D6A8E23B6432AE9CE6677BFCCAFD2F60B19235F5C83B55E779BA4ABB95F19617E79CF9359BD5920ACD9B5E2ABD1ECF031428BF14054E0FEB926EDA8741D1551FEBE8028CC58461DFA7BA1B91944044984FD6DB2C138E0971C009FAF2C5AE8D03884AD2B0C14184D560399566D59019EC87F4A6E12568B686502457E9CD711019FE8298C1670661DD420860DCE8260466B3CAB31135B660EE145993D533F2D007938B8E8305239BAEEBD3AA054400DF7EB7662D0F55D8246B5E664EC650870C6159AA6FDC405AFDEED4C4566F555BC2B0E411195E08160A4A8E41911",
        "e": "24574A2D1D15",
        "testType": "GDT",

 {
            "tcId": 5,
            "message": "2CF40704845553A93BB730E8341655811233634A1677342282CBE18E38CE6837FEB0E9A9AEB891BAE8E99B660646910D1BBD612F7B0BF2159EB5BC150F3C93D71D362EC624713E7363DE55088CD3D83FE0F0CACCA5866D2D760D1BED2CF4993EF2283ADE8672FEE68A07B6E9386823BAA3E909A87A85FF5815B5382257C97B19",
            "signature": "301372BD7A2C548B9BF7C6439111D5BE58C0A9C8AFF161487511E4BF75680F6CCF790EA270C47C74938E7B07671C7DB93C00156E4ED6CAD978AB9B969AD80D799FAF815A363BFB8CE4A39B64040A22686C59E245021CBA6EC0988268FD2B7991DD8898264CEB1E9A75A19A7F9F8EB2F42EE089B09757B06A7910BACBCF615D84B3D180EA07AEA12B5AA09876D810D7683FDA103EB2597728D7D69E12254595617D9E9778C6FF3E2CEB16811C45AE85135A2A198282DA6C659AC4102313CA22D903AB091151390A5BE374C1AA2534E998B098A4C309A8A56AC5EA415CFD2405E824718AD37FC05EB9EBD309B7D9E558065DA8EF6C5B8B95A1B8913CCA1CCBDD4C"
          },

After manually decrypting the signature we arrived at:

Dumping the ASN1 yeilded:

Sequence
    Sequence
        ObjectIdentifier(2.16.840.1.101.3.4.2.4)
        NULL
    DER Octet String[28] 
        e37c4dbb59232e80ab47727827c71d0c84dd592167f4d26beef87100            |MY#.Grx'Y!gkq

"2.16.840.1.101.3.4.2.4" is the oid for SHA224"

Message digest when calculated with SHA3 implementation is correct.

Please let me know if you need any more information.

MW

[livebe01]

Thanks @mwcw. Do you know where the OIDs for SHA3 are defined by chance?

[mwcw]

Thanks @mwcw. Do you know where the OIDs for SHA3 are defined by chance?

Hi

Take a look at this

https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration

MW

[livebe01]

Ah, I’d been there, but only to the bottom of the page. Thanks MW!

Ben

On Mar 28, 2023, at 5:34 PM, MW @.***> wrote:

Thanks @mwcwhttps://github.com/mwcw. Do you know where the OIDs for SHA3 are defined by chance?

Hi

Take a look at this

https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration

MW

— Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/ACVP-Server/issues/257, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGMA5AUXWNV7M6VZJXFO2SLW6NKMTANCNFSM6AAAAAAWJYY6GM. You are receiving this because you commented.Message ID: @.***>

[livebe01]

@mwcw Do you understand or have any suggestions for how to go from an OID to its hex equivalent? For example, we have the hex for SHA1 through SHA2 512/256 defined here and the OIDs are defined as the following in RFC 4055 Section 2.1: id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 }

I see the OIDs for SHA3 on https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/algorithm-registration#External are defined as the following. But I don't know how to convert those definitions to hex. id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 } id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 } id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 } id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 }

PS I'll keep looking to understand this better...

[mwcw]

Hi,

Ah, okay, those oids are for HMAC, not the same thing. Just to clarify, a PKCS 1.5 signature is actually a DER encoding of a DigestInfo structure encrypted with the RSA private key using PKCS 1.5 padding.

The DigestInfo structure is based on

   DigestInfo ::= SEQUENCE {
       digestAlgorithm DigestAlgorithm,
       digest OCTET STRING
   }

DigestAlgorithm is an AlgorithmIdentifier, in this case made up of (note this is a very old school way of describing it)

    AlgorithmIdentifier ::= SEQUENCE {
       algorithm OBJECT IDENTIFIER,
       parameters ANY DEFINED BY algorithm OPTIONAL
   }

You can find more details on this in RFC 8017 ( https://www.rfc-editor.org/rfc/rfc8017.html ) It uses the modern approach to describing the ASN.1 but at the end of the day it's the same thing. algorithm in this case is the OID for the digest algorithm.

For SHA-3 the prefixes for the different hashes would look like:

SHA3-224: 302d300d06096086480165030402070500041c SHA3-256: 3031300d060960864801650304020805000420 SHA3-384: 3041300d060960864801650304020905000430 SHA3-512: 3051300d060960864801650304020a05000440

which are based on the encodings for:

hashAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 2 }

id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 }

id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 }

id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 }

id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 }

The pattern is basically the same for each, but to break up SHA3-224

30 - sequence 2d - length of body 30 - sequence 0d - length of body 06 - object identifier 09 - length of object identifier 608648016503040207 encoding of id-sha3-224 05 - null 00 - length of null 04 - octet string 1c - length of octet string

after that comes the actual digest value - in this case 28 (hex 1c) octets.

Note, the NULL is an "historical artifact" as such has caused a lot confusion over the years so for these digests you should probably follow the pattern with SHA-2 and accept either NULL or ABSENT for the parameters. FIPS 186-5 defers to RFC 8017, which states:

-- However, implementations MUST accept AlgorithmIdentifier values -- both without parameters and with NULL parameters.

on this as well). Absent parameters are easy to pick up - it reduces the length of the prefix by two bytes.

The prefixes for ABSENT parameters are:

SHA3-224: 302b300b0609608648016503040207041c SHA3-256: 302f300b06096086480165030402080420 SHA3-384: 303f300b06096086480165030402090430 SHA3-512: 304f300b060960864801650304020a0440

If you look at the SHA3-224 encoding you can see the length byte for the outer sequence is now 2b instead of 2d, and the inner sequence holding the AlgorithmIdentifier sequence is now 0b rather than 0d.

What you produce is kind of up to you, we have found we've caused the least grief by always including the NULL (so the slightly longer string). We'll accept either NULL or ABSENT though, as we'd recommend you do (there's always someone who leaves them out, and they'll probably be a bit cross if the ACVP server knocks them back because of it).

[livebe01]

Thanks. I appreciate the explainer.

[dghgit]

Apologies for sounding like a bit of a nag, but how is the progress looking on this one and also #258 ? We were going full throttle for a 140-3 submission with 186-5 prior to running into these, so it's starting to have an impact on the schedule - our lab is going to have to suspend work on the certification and reschedule us. If there is anything myself or @mwcw can do to help, please let us know. Thanks.

[jbrock24]

Hi @dghgit, this is my highest priority for this week. I am actively working on it and thank you for your help.

[dghgit]

Thanks, appreciate the quick response.

[jbrock24]

No worries, I have submitted the changes for testing, hopefully release it next week. I'll post here when it's available for use.

[dghgit]

Great, we'll give it a whirl as soon as it goes up. Thanks.

[livebe01]

The fix for this is now on Demo in release v1.1.0.29.

[dghgit]

Hi, slight issue on the ASN.1 for the prefixes for NULL parameters should be:

302d300d06096086480165030402070500041c 3031300d060960864801650304020805000420 3041300d060960864801650304020905000430 3051300d060960864801650304020a05000440

What's in there at the moment is the length for ABSENT parameters (byte 2) but the NULL parameters are present. The OIDs appear to be correct I think if the prefix is fixed so the length is correct these will now be good to go.

[jbrock24]

@dghgit I'll look into this, thanks.

[jbrock24]

OK, I see the error and have fixed it, sorry about that. It will be out with the next HOTFIX ASAP.

[livebe01]

The fix for this is on Demo with release v1.1.0.29-hotfix-1

[dghgit]

It's a print! We've been able to submit successfully for both SigGen and SigVer. Thanks!

[jbrock24]

Great! Once this goes to Prod we'll close this out, appreciated.

[livebe01]

The fix for this is on Prod in release v1.1.0.29-hotfix-1.