Closed smuellerDD closed 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.
I have not tested cSHAKE before so I cannot tell.
Besides, I see the same issue for KMAC
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.
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.
@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?
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
environment Demo
testSessionId 236102
vsId 925440
The customization string contains the following:
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.