Expectation for KTS-OAEP-basic VAL test

[mgpirret]

It is not totally clear on how to support the KTS-OAEP-basic testing. I don't find anything for KTS that is similar to the KASVS document that describes what the tests do. Based on how other ACVP tests work I interpret it as:

• "AFT initiator" - Functional test that asks IUT to generate a random 256 bit key and encrypt it with the server's key (server, serverE). IUT returns the 256-bit key as dkm and the encrypted key as iutC
• "AFT responder" - Functional test that asks IUT to decrypt a provided ciphertext (serverC) using the provided IUT keypair (iutE, iutP, iutQ, iutD, iutN). IUT returns the decrypted key as dkm.
• "VAL initiator" - Validity test that passes into IUT the server's public key (serverE, server) and a key to wrap (dkm). IUT has to determine if that input is valid, but I don't know what is being asked for
• "VAL responder" - Validity test that passes in the IUT's keypair (iutE, iutP, iutQ, iutD, iutN), the server's ciphertext (serverC), and the expected plaintext key (dkm). IUT needs to return a true/false value if the decryption of serverC produces dkm.

Hope you can confirm and clarify my understanding. In particular, could you comment on the expectation for what the IUT is to be doing for the italicized "val initiator" test?

[Kritner]

It's been a few months since i looked at the IFC testing, but at a glance that all looks correct. The idea behind both "initiator" and "responder" VAL tests is that the ACVP server provides a full key agreement, acting as both party U and party V, and the IUT is expected to state if that key agreement is valid or not - basically run the key agreement with the provided parameters and make sure you do (or don't) come up with the tag provided by the test case. In the end it's just "testPassed": true or "testPassed": false.

Last time we checked there wasn't any actual cases of testing of the IFC flavors of KAS/KTS on demo, and due to that I had planned on changing the registration around a bit, namely:

Current KAS IFC registration:

root
    scheme1
        key generation methods
            modulo
            etc...
        etc...
    scheme2
        key generation methods
            modulo
            etc...
        etc...

where the above would allow a specifying of "key generation methods" on a "per scheme basis" where each "key generation method" could support multiple (and potentially differing) sets of modulo.

I'm not sure if it makes sense to have this complexity in the registration, and I've brought it up internally to perhaps change this part of the registration:

root
    scheme1
    scheme2
    key generation methods
    supported modulo
    etc...

so that the key generation methods are independent of the schemes, and the modulo are independent of the key generation methods.

I'm pretty sure this is a valid assumption to make, but up until now we hadn't had anyone testing this particular algorithm. So since we now do have someone testing it (you), does this sort of change make sense to you?

I had planned on making this change shortly, especially since no one had yet tested against KAS/KTS IFC, but now that someone is, I can throw it out there to get your thoughts! 👍

[mgpirret]

Yes, I would agree the more decoupled version makes more sense at least from our module's context.

For the validity test I do understand the goal of testing both endpoints of KTS. But my issue is more that I don't know what we we need to do for the initiator validity test when we are doing RSA-OAEP based KTS. As the initiator we are given a public key (serverN, serverE) and a dkm (which I interpret to be a plaintext key). From the initiator's standpoint what criteria are they supposed to use to determine if the input data is valid? Since OAEP is a randomized algorithm we certainly wouldn't be able to validate our ciphertext to a known good ciphertext. And since we are talking about RSA keys, there isn't a whole lot that we can do to validate the public key. So what are we supposed to do here?

[Kritner]

Ah, sorry about that, it's been a few months since I put together this set of tests and of course you're correct. I suppose in all the KAS schemes we're always running a KDF that takes in information from both parties to lead to a shared secret and eventually derived keying material. In this case however, we're encrypting an already existing key with the other parties public key. (I realize you realize this, just reiterating for my own, and the issue's sake.)

For an initiator val test, it seems it would make more sense for the initiator to produce a C value for comparison to the one the prompt file sends (or will send), the result of which being "testPassed": true or "testPassed": false like we have been doing in the previous val tests for KAS and KTS. From a responder val test perspective, it still makes sense to validate the K sent in the prompt file (though it may be labeled as dkm IIRC).

Hopefully that all makes sense. I'll have to put in some changes on our end to handle the separate generation/validation flow from the KTS-basic initiator perspective.

[smuellerDD]

Am Freitag, 7. August 2020, 14:59:18 CEST schrieb Russ Hammett: Hi Russ, Mat,

Hopefully that all makes sense. I'll have to put in some changes on our end to handle the separate generation/validation flow from the KTS-basic initiator perspective.

Thanks a lot for the discussion. Russ, may I ask to update the test spec a bit with the hints given in this thread? Other users at a later time may stumble over it. Thanks a lot. Ciao Stephan

[Kritner]

Yup @smuellerDD will do. It's been hinted at in a few other issues on the repo, but we're doing an overhaul of the "source" for all the specification documents. We're hoping to be able to get that integrated into this repository soon, but in the meantime https://celic.github.io/acvp-metanorma/ contains the updates (though not the updates from this issue as of yet).

[mgpirret]

Regarding the initiator val test I agree that what you suggest below would make sense if OAEP was a deterministic algorithm. However, this isn't the case. The algorithm is randomized. So each time we would generate an entirely random ciphertext.

For an initiator val test, it seems it would make more sense for the initiator to produce a C value for comparison to the one the prompt file sends (or will send), the result of which being "testPassed": true or "testPassed": false like we have been doing in the previous val tests for KAS and KTS. From a responder val test perspective, it still makes sense to validate the K sent in the prompt file (though it may be labeled as dkm IIRC).

[Kritner]

Ah right, I guess in order to actually test this for the initiator the IUT would need to be able to inject specific entropy provided by the prompt file.

I'll talk through some of this internally and update when something comes of it. Right now I'll probably just move forward with disabling the VAL type tests for KTS schemes, but that may reevaluate based on some our internal conversation.

I'll keep this issue open until at least the disabling of VAL type tests for KTS schemes has made it out to demo.

[Kritner]

VAL tests for KTS has been removed on demo, I have additionally added a property or two that was missing from the prompt file. Hopefully this covers everything, but let me know if there are any additional changes needed and we can discuss and/or I can get it added.