ML-KEM: Encapsulation - ACVP server not interested in SS?

[smuellerDD]

The test response returned to the server and accepted by it only contains the Kyber ciphertext. I would be wondering why it does not want the shared secret considering it is also a result of the encap operation?

[celic]

You are right. The server is checking whether or not the implicit rejection occurs from decapsulation based on the ciphertext, but it is not comparing the resulting shared secret with the value computed by the IUT.

It wasn't apparent that there was any assurance to gain by checking the shared secret, given that it is the result of a couple hash calls. It isn't a problem to collect and verify though. I do agree it feels incomplete in the current state and am inclined to update the testing.

[smuellerDD]

Am Donnerstag, 11. April 2024, 22:05:40 CEST schrieb Chris Celi:

Hi Chris,

You are right. The server is checking whether or not the implicit rejection occurs from decapsulation based on the ciphertext, but it is not comparing the resulting shared secret with the value computed by the IUT.

It wasn't apparent that there was any assurance to gain by checking the shared secret, given that it is the result of a couple hash calls. It isn't a problem to collect and verify though. I do agree it feels incomplete in the current state and am inclined to update the testing.

I figured out what the problem is:

Your code gen-val/src/orleans/src/NIST.CVP.ACVTS.Libraries.Orleans.Grains/Pqc/ OracleObserverMLKEMDecapCaseGrain.cs contains in method DoWorkAsync:

    switch (_param.Disposition)
    {
        case MLKEMDecapsulationDisposition.None:
            // No change
            break;

        case MLKEMDecapsulationDisposition.ModifyCiphertext:
            // Flip the last bit in the ciphertext
            ciphertext.Bits.Set(0, !ciphertext.Bits.Get(0));
            break;
    }

Now, when I implement the (reverse) bit flip in my code, the otherwise failing responses now turn into the expected responses. But since I cannot detect where the bit flip is, all my previously passing results now fail (i.e. calculate a wrong shared secret), naturally.

I.e. my KEM implementation calculates the right data.

IMHO, the bit flip, however, is not appropriate to validate KEM, because KEM does not have the means to detect such bit flip other than it simply calculates the wrong shared secret.

Could you please shed some light onto what you try to achieve/test and which part of the specification shall catch this flip?

With that, you do not need to send me the requested intermediate data.

Ciao Stephan

[celic]

It doesn't appear that the validation side of these tests is set up properly. We provide inputs to you in the form of a supposed "good" encapsulation. The IUT decapsulates it and provides back the computed shared secret. The server will verify if the computed shared secret comes from the K-PKE.Encrypt operation (the no modification case) or from the implicit rejection (the modification case). Currently the server isn't doing the check to see if the resulting key is from implicit rejection and it is failing the case because the shared secret didn't match the "good" encapsulation we used as a starting point, before modification.

[livebe01]

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

[smuellerDD]

Confirmed, working