search

usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
46 stars 16 forks source link

cSHAKE: customization string is non-ASCII?! #197

Closed smuellerDD closed 2 years ago

smuellerDD commented 2 years ago

environment Demo

testSessionId 236102

vsId 925440

The customization string contains the following:

            "tcId": 1,
            "msg": "3EBEA81D5496728413DB36D284499408BA1AADC4A3B7854B2AD0FE74B4F1D54DC4530D101756212C91EAD2053F9AAECB251F127E459B4C4CCEC07376C2036FE5E1756D3314BA27CD99F360EF03540C9E46C17723D7B7",
            "len": 688,
            "functionName": "",
            "customization": "5v_Yx(OB-WM\u0027A^_\u0060h;[9?X)wkFc),6Lt\u003EBy^i\u003C~-j|-Fif\u0027xZ5ZF7 ,ZngnRDG7v,Wh~c!vK;NMAKb.%?iLvZ\u0026^=6\u003Eo#MKhCf6;2}(5X\u003E/,gRj/,Xi4Yy@;\u0026xJhE2s}nf",
            "outLen": 496
          },

That does not look like ASCII to me with the UTF-16 encodings inbetween. There seems to be no indication how to handle these characters in the test spec.

livebe01 commented 2 years ago

Thanks for reaching out @smuellerDD. We're looking into this on our end. Is this the first time you've run into this? I'm wondering if this has always been an issue or if this is something new.

smuellerDD commented 2 years ago

I have not tested cSHAKE before so I cannot tell.

Besides, I see the same issue for KMAC

smuellerDD commented 2 years ago

As a side note: I successfully tested my KMAC implementation (which directly uses the cSHAKE implementation) with hex string - all passes. With these "ASCII" strings, I get failures. The cSHAKE completely fails with the "ASCII" strings - but I believe it is correctly implemented because (a) when using hex strings I get the proper results, and (b) KMAC succeeds.

livebe01 commented 2 years ago

Thanks for the update @smuellerDD. We've replicated the issue on our end as well, but don't have a fix for it as of yet. I'm in the middle of something at the moment, but I should be able to pick this up/look into this further later this week.

livebe01 commented 2 years ago

@smuellerDD, our describing customization as an "ASCII customization string (between 0 and 161 ASCII characters in length)" is not correct. A more correct description would be that it is a string containing between 0 and 161 characters from the set of U+0020 through U+007F (which corresponds with the ASCII printable characters). The string would necessarily be Unicode as JSON strings should be Unicode.

The \uXXXX that you're observing in the customization strings appear to be an artifact of our JSON serializer. As per RFC 7159, in a JSON string, any character may be escaped. In this case, our serializer defaults to escaping the '+<>`& characters. When you deserialize the customization string, I believe that your deserializer should be unescaping those characters? Can you check this on your end, i.e., whether your deserializer is unescaping the strings and if not, whether this can be enabled?

smuellerDD commented 1 year ago

Am Montag, 14. März 2022, 20:02:24 CET schrieb livebe01:

Hi livebe01,

Thanks for reaching out @smuellerDD. We're looking into this on our end. Is this the first time you've run into this? I'm wondering if this has always been an issue or if this is something new.

It is the first time I am using cSHAKE test vectors. So, I cannot compare it to previous experiences (same with the KMAC issue I reported yesterday).

Ciao Stephan