search

usnistgov / ACVP-Server

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

ML-KEM decap: some test vectors fail #323

Closed smuellerDD closed 5 months ago

smuellerDD commented 5 months ago

environment Demo

testSessionId 503548

vsId 2283720

The verdict returned by the server shows that some responses fail. Considering that there is no full specification out, can you please hint to the failure type? E.g. the modulus check is failing? If so, how should that be reported?

celic commented 5 months ago

I don't think it can be helped on ML-KEM Decapsulation. You get down to the implicit rejection statement and it either succeeds or fails. It is not necessarily possible in our code to see at what point the implementation deviates during the K-PKE.Decrypt operation or following K-PKE.Encrypt operation.

The code is available in this repository and can be run manually. Or if you have a particular test case you want to see intermediate values, I can do that separately.

smuellerDD commented 5 months ago

Am Donnerstag, 11. April 2024, 22:13:39 CEST schrieb Chris Celi:

Hi Chris,

I don't think it can be helped on ML-KEM Decapsulation. You get down to the implicit rejection statement and it either succeeds or fails. It is not necessarily possible in our code to see at what point the implementation deviates during the K-PKE.Decrypt operation or following K-PKE.Encrypt operation.

The code is available in this repository and can be run manually. Or if you have a particular test case you want to see intermediate values, I can do that separately.

Could I ask you to send the intermediate values for vsID 2283720, tcID 3?

Thanks a lot

Ciao Stephan

smuellerDD commented 5 months ago

Am Donnerstag, 11. April 2024, 22:13:39 CEST schrieb Chris Celi:

Hi Chris,

I don't think it can be helped on ML-KEM Decapsulation. You get down to the implicit rejection statement and it either succeeds or fails. It is not necessarily possible in our code to see at what point the implementation deviates during the K-PKE.Decrypt operation or following K-PKE.Encrypt operation.

The code is available in this repository and can be run manually. Or if you have a particular test case you want to see intermediate values, I can do that separately.

Please note that I downloaded in total 3 sets of Kyber Decapsulation. For all about half of all my responses were rejected.

Then I used the latest version of gen-val/src/crypto/test/ NIST.CVP.ACVTS.Libraries.Crypto.Kyber.Tests/KyberTests.cs and manually iterated over all vectors (for Kyber 1024 - as this is my current focus). For all of them, my shared secrets match the ones in that file.

How come that for the test file, all values match whereas for newly generated data, I encounter failures, I wonder.

Ciao Stephan

celic commented 5 months ago

I identified the issue here. I may have mentioned it in another issue on GitHub. Essentially when the IUT would provide back the implicit rejection shared key, the server was trying to check if it matched the valid shared key computed before modifications were made. This has been fixed and will be pushed to Demo soon. If you still need intermediate values after this fix is published, please let me know.

livebe01 commented 5 months ago

This issue is addressed on Demo as of this afternoon's v1.1.0.34 hotfix deployment.

smuellerDD commented 5 months ago

Status: ML-KEM keygen, enc and dec passes completely now (tested 1024 so far).

For the records of peer developers: The changes documented in https://atsec-information-security.blogspot.com/2023/11/pqc-kyber-and-dilithium-state-of-draft.html must be applied.