search

usnistgov / ACVP

Industry Working Group on Automated Cryptographic Algorithm Validation
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program
172 stars 66 forks source link

KTS-OAEP: where is the key material #1098

Closed smuellerDD closed 3 years ago

smuellerDD commented 3 years ago

Protocol Section KAS SP800-56B rev 2, test case for registration:

        "algorithm":"KTS-IFC",
        "revision":"Sp800-56Br2",
        "function":[
          "partialVal"
        ],
        "iutId":"0123456789abcdef",
        "keyGenerationMethods":[
          "rsakpg1-basic",
          "rsakpg1-prime-factor",
          "rsakpg1-crt"
        ],
        "modulo":[
          6144,
          8192,
          2048
        ],
        "fixedPubExp":"010001",
        "scheme":{
          "KTS-OAEP-basic":{
            "kasRole":[
              "initiator",
              "responder"
            ],
            "ktsMethod":{
              "hashAlgs":[
                "SHA2-256",
                "SHA3-384"
              ],
              "supportsNullAssociatedData":true,
              "fixedInfoPattern":"uPartyInfo||vPartyInfo||literal[affeaffeaffe]",
              "encoding":[
                "concatenation"
              ]
            },
            "l":1024
          }
        }
      }

Protocol Question The registration is intended for a validation of the basic RSA OAEP as specified in section 9.2.3 SP800-56AB ref 2.

In the specification I fail to identify:

When looking at the section 9.2.3, I would only expect for the initiator:

Thanks for any pointers.

smuellerDD commented 3 years ago

I think I got it working:

initiator:

responder:

Would it make sense to add this to the spec?

nidhidamodaran commented 3 years ago

@smuellerDD isn't server/iut ID part of additional data ?

smuellerDD commented 3 years ago

Yes, that would be part of the additional data - but for a pure OAEP testing without any subsequent KDF, the test vector will not give you any additional data (as expected). And as almost all IUTs I deal with implement OAEP independent of the KDF, I plan to test OAEP separately from the KDF. This approach is accepted by NIST via the latest IG.

Kritner commented 3 years ago

maybe it's just semantics, but I thought that any KDF is outside the scope of KTS testing anyway. KTS is just more or less wrapping a key out of band, the IUT/ServerIds that are provided are a part of the AssociatedData that can go into the wrap/unwrap operation.

I want to make sure we're on the same page here, the KTS testing that's in place should be just testing against the OAEP implementation from the perspective of the initiator and/or responder - no KDF involved.

Does that answer the outstanding questions? And yes, feel free to update anything in the specification to make things clearer, if not I'll get to it eventually.

nidhidamodaran commented 3 years ago

Thanks for the clarification @smuellerDD @Kritner . I have a question regarding the value of "l" too. I see the dkm size is different from value of l. Is l really the size of dkm ?

smuellerDD commented 3 years ago

Am Dienstag, dem 05.01.2021 um 02:36 -0800 schrieb Russ Hammett:

maybe it's just semantics, but I thought that any KDF is outside the scope of KTS testing anyway.  KTS is just more or less wrapping a key out of band, the IUT/ServerIds that are provided are a part of the AssociatedData that can go into the wrap/unwrap operation.

Well, not sure what you mean with "outside", but the test spec clearly defines that KTS = OAEP + optional KDF. You are right that the KDF wraps the data, but a large number of IUTs implement the basic asymmetric operation (KTS: OAEP / RSA operation, KAS: DH) separately from any KDFs. Thus, a test of both in unison may be a challenge.

Hence, I am looking for the tests that does not include the KDFs in the KAS/KTS tests. The KDFs are tested separately with the 56C tests for me.

I want to make sure we're on the same page here, the KTS testing that's in place should be just testing against the OAEP implementation from the perspective of the initiator and/or responder - no KDF involved.

Strange, the spec seems to define one/twostep KDF configurations to include the KDF into the OAEP testing. It seems I am missing something here.

Does that answer the outstanding questions? And yes, feel free to update anything in the specification to make things clearer, if not I'll get to it eventually.

I think the issue is that

  1. the actual parameters in the spec are not fully clarified what they actually mean

  2. the actual test approach that shall be applied by the IUT is not really clear (e.g. the IUT has to generate the key).

Ciao Stephan

Kritner commented 3 years ago

From @nidhidamodaran:

Thanks for the clarification @smuellerDD @Kritner . I have a question regarding the value of "l" too. I see the dkm size is different from value of l. Is l really the size of dkm ?

That may be a mistake, do you have a vector set ID from demo showing this behavior? I'll need to take a look and confirm/fix.

maybe it's just semantics, but I thought that any KDF is outside the scope of KTS testing anyway. KTS is just more or less wrapping a key out of band, the IUT/ServerIds that are provided are a part of the AssociatedData that can go into the wrap/unwrap operation.

Well, not sure what you mean with "outside", but the test spec clearly defines that KTS = OAEP + optional KDF. You are right that the KDF wraps the data, but a large number of IUTs implement the basic asymmetric operation (KTS: OAEP / RSA operation, KAS: DH) separately from any KDFs. Thus, a test of both in unison may be a challenge.

Can you point to the part of the spec that says KTS = OAEP + optional KDF? is it the SP? or our github specification? Sorry these documents have been out of mind for a few months now, and I want to make sure I'm no misinterpreting anything.

Hence, I am looking for the tests that does not include the KDFs in the KAS/KTS tests. The KDFs are tested separately with the 56C tests for me.

all of KAS testing has the SSC testing available to it - ECC, FFC, and IFC. SSC testing does not (and cannot as far as I can tell) apply to KTS, as there is no "shared secret z" computation for the KTS based schemes, as the KTS schemes are just a means of transporting an already existing key from one party to another.

I want to make sure we're on the same page here, the KTS testing that's in place should be just testing against the OAEP implementation from the perspective of the initiator and/or responder - no KDF involved.

Strange, the spec seems to define one/twostep KDF configurations to include the KDF into the OAEP testing. It seems I am missing something here.

Can you point me to this? If it's specified as such in our github specification, it probably shouldn't be, or something would need clarification, because there is no KDF with the KTS schemes from what I can remember.

  1. the actual parameters in the spec are not fully clarified what they actually mean

This can be updated, was it l, iutId, and serverId? Anything else?

  1. the actual test approach that shall be applied by the IUT is not really clear (e.g. the IUT has to generate the key).

I'm assuming this question is specific to KTS, not the KAS schemes?

image

Party U will always be the "provider of the key" in KTS schemes, how that key is arrived at is the thing that I'm stating is out of scope of the KTS testing that we perform. If the IUT is acting as party U for a test case, then it should be the one supplying the key via C, if the IUT is party V, they will be provided a C via our prompt file, and should be able to retrieve the unwrapped key.

Like I said, it's been several months since this testing was put together, so I may have misstated some things, but I'd like to help us work through this!

smuellerDD commented 3 years ago

Am Dienstag, dem 05.01.2021 um 04:41 -0800 schrieb Russ Hammett:

From @nidhidamodaran:

Thanks for the clarification @smuellerDD @Kritner . I have a question regarding the value of "l" too. I see the dkm size is different from value of l. Is l really the size of dkm ?

That may be a mistake, do you have a vector set ID from demo showing this behavior? I'll need to take a look and confirm/fix.

maybe it's just semantics, but I thought that any KDF is outside the scope  of KTS testing anyway.  KTS is just more or less wrapping a key out of band,  the IUT/ServerIds that are provided are a part of the AssociatedData that  can go into the wrap/unwrap operation.

Well, not sure what you mean with "outside", but the test spec clearly defines that KTS = OAEP + optional KDF. You are right that the KDF wraps the data, but a large number of IUTs implement the basic asymmetric operation (KTS: OAEP / RSA operation, KAS: DH) separately from any KDFs. Thus, a test of both in unison may be a challenge.

Can you point to the part of the spec that says KTS = OAEP + optional KDF?  is it the SP? or our github specification?  Sorry these documents have been out of mind for a few months now, and I want to make sure I'm no misinterpreting anything.

``[[scheme_caps_table]] .KAS IFC Capabilities JSON Values |=== | JSON Value| Description| JSON Type| Valid Values| Optional

| kasRole| Roles supported for key agreement| array| initiator and/or responder| No | kdfMethods| The KDF methods to use when testing KAS schemes. | object| <>| Not optional for KAS schemes. | ktsMethods| The KTS methods to use when testing KTS schemes. | object| <>| Not optional for KTS schemes. | macMethods| The MAC methods to use when testing KAS or KTS schemes with key confirmation. | object| <>| Not optional for KAS/KTS schemes making use of key confirmation. | l | The length of the key to derive (using a KDF) or transport (using a KTS scheme). This value should be large enough to accommodate the key length used for the mac algorithms in use for key confirmation, ideally the maximum value the IUT can support with their KAS/KTS implementation. Maximum value (for testing purposes) is 1024.| integer| 128 minimum without KC, 136 minimum with KC, maximum 1024.| No`



kdfMethods -> not optional for KAS schemes, but optional for KTS schmes as I
read it.

But I see your point, after reading 56B chapter 5 and 9 more carefully, a KDF
is only applicable to KAS and not KTS. Sorry, my bad then.

> 
> -----
> 
> > Hence, I am looking for the tests that does not include the KDFs in the
> KAS/KTS tests. The KDFs are tested separately with the 56C tests for me.
> 
> all of KAS testing has the SSC testing available to it - ECC, FFC, and IFC. 
> SSC testing does not (and cannot as far as I can tell) apply to KTS, as
> there is no "shared secret z" computation for the KTS based schemes, as the
> KTS schemes are just a means of transporting an already existing key from
> one party to another.

Right, and KTS covers this. Now that I see that a KDF is not applicable to
KTS, my concern regarding the KDF vanishes.
> 
> -----
> 
> > >  I want to make sure we're on the same page here, the KTS testing that's
> > > in
>  place *should* be just testing against the OAEP implementation from the
>  perspective of the initiator and/or responder - no KDF involved.
> 
> > Strange, the spec seems to define one/twostep KDF configurations to
> > include
> the KDF into the OAEP testing. It seems I am missing something here.
> 
> Can you point me to this? If it's specified as such in our github
> specification, it probably shouldn't be, or something would need
> clarification, because there is no KDF with the KTS schemes from what I can
> remember.

See above, please ignore my comment.
> 
> -----
> 
> > 1. the actual parameters in the spec are not fully clarified what they
> actually mean
> 
> This can be updated, was it `l`, `iutId`, and `serverId`? Anything else?
> 
> 2. the actual test approach that shall be applied by the IUT is not really
> clear (e.g. the IUT has to generate the key).
> 
> I'm assuming this question is specific to KTS, not the KAS schemes?  
> 
> ![image](   
> https://user-images.githubusercontent.com/8814983/103647038-aa564a00-4f28-11eb-8d0e-d57f197a6823.png
> )
> 
> Party U will always be the "provider of the key" in KTS schemes, how that
> key is arrived at is the thing that I'm stating is out of scope of the KTS
> testing that we perform.  If the IUT is acting as party U for a test case,
> then it should be the one supplying the key via `C`, if the IUT is party V,
> they will be provided a `C` via our prompt file, and should be able to
> retrieve the unwrapped key.
> 
> Like I said, it's been several months since this testing was put together,
> so I may have misstated some things, but I'd like to help us work through
> this! 

I think it is not fully clear with the picture and the description. I was
under the impression that the test is a known-answer test (as it could be
implemented as such). But instead it is implemented such that the key that is
to be exchanged must be generated by the IUT. This very fact was not clear to
me and it took me a bit to get to this conclusion.

Thanks
Stephan
nidhidamodaran commented 3 years ago 
           {
              "tcId": 20,
              "iutN": "A818BD",
              "iutE": "18B0BB44AA53",
              "iutP": "B984A....",
              "iutQ": "E7F5B...",
              "iutDmp1": "AAB0C...",
              "iutDmq1": "8315...",
              "iutIqmp": "B166...",
              "serverC": "78AF5..."
           }

For the responder validation part, I am trying to decrypt serverC data by deriving iut private key given in the json. But somehow RSA_private_decrypt with RSA_PKCS1_OAEP_PADDING throws padding mismatch error. Am i missing something ?

smuellerDD commented 3 years ago

Am Dienstag, dem 05.01.2021 um 07:31 -0800 schrieb Nidhi Damodaran:

               {                   "tcId": 20,                   "iutN": "A818BD",                   "iutE": "18B0BB44AA53",                   "iutP": "B984A....",                   "iutQ": "E7F5B...",                   "iutDmp1": "AAB0C...",                   "iutDmq1": "8315...",                   "iutIqmp": "B166...",                   "serverC": "78AF5..."                }  For the responder validation part, I am trying to decrypt serverC data by deriving iut private key given in the json. But somehow RSA_private_decrypt  with RSA_PKCS1_OAEP_PADDING throws padding mismatch error. Am i missing something ?

If it is a VAL test, this is expected and you should return this failure. For an AFT, this is not expected.

nidhidamodaran commented 3 years ago

Sorry @smuellerDD , testtype is AFT. I am expected to return dkm. Is there any operation to be done prior to calling decrypt on serverC ?

smuellerDD commented 3 years ago

Am Dienstag, dem 05.01.2021 um 07:36 -0800 schrieb Nidhi Damodaran:

Sorry @smuellerDD , testtype is AFT. I am expected to return dkm. Is there any operation to be done prior to calling decrypt on  serverC ?

Nope, it is a straight decrypt after importing the values. But maybe you have a padding issue? Check that the input values all have the expected lengths - if not, prepend padding zeros to those values.

nidhidamodaran commented 3 years ago 
         {
           "tcId": 8,
           "iutN": "A97E25EC26FBDB464F81CA5E1BBE412485961ECE7C0003E8EDFC63B6946F6B3E42B13235F7FC4EF52AD5719C67B8BF5F492CF3D7721AEAD0DEE44B867BF55C388BE3B2D4FD04737846032DA940B8596D423CE2D965A6FC724600411BCF2C5BA4931EE7E8943718366EC33D7079F58487161F9951CFD38CC7E3E29264677F744BD09C7D0CD1FC1B9B417D3C1CFF53A0B32354CEC86719379632BB1A4E9F3834159BF39FED2A7A2A16F8AA45524712AE6FCF31B87BCDB8C77434FCBEB061006D38F5C7FCB62CB44669A28EFAD975D31E30C64083168AC0F97922AA3C0FA214C2F1F492A16F6002A3CE003C64DBF1525C5EEFEEBE411E6721567858B70E0F4E6981",
           "iutE": "3BDEA4775FE1",
           "iutP": "DD03D104A0691B7CD884FE341A62283961814F082DA1725E76B08FF15530C110E42FD8CA4A663507F01DE2BEBCB321750C7E78C6CAE6C6B6CE1B6AD5710B9ABA43BAE73BD834B7DA4719EFF357417AE08601FDF0EB05CBCC6AB0FF01407C20DF113A003693A776096E64CB95B33166CE1DAB5292EBABF543F07BE34E3E253E13",
           "iutQ": "C45280305C0A92347463D05A94CA75BA5145EF0417855E5574319ACC80C135FE5E86C16FA172039502689BBC568315C737A59C7FD46D2886C221A35FA0959C102026DDAA92AC5FEEC5C372400C207718903A611DD155253C31541C0061C85975A8A7DCCD9BA60298C26ED5FAA959DADE210427F90A45B7FCF479509544215C9B",
           "iutD": "0720E1FD614A1A00B649FCC0147E3A88F0AE7AA3F5D7FD71A8A220DD83EBE88AB490CACB2F6BD071532D4F8C87C8C4C72A3B3298B7B6377344CCD14D32BC973434E4B63ED6F8690E9316B5CB73BBFB74143B85D66FA31A65EB913F8E2931AB173DA04F79EE5E97401D3C98BCACBA35CB2BE9EEBCD6A6DCD8B3C5322807F96D0AEA3C04AA3CD123735C1AF0E08F86D435912CF7188E435A7C224AE954329DEB4B77BE2A5C529EA8D20E059BD891F8732AA4AC279C555EF7F5709A7CD36CABEFB5B99E13D00B1A18CC2ED056E1BB6FB71B6AAEAD4CBE453EF04A412D92A6850EAC6765D091A3F9EF5844EB695E754512077D6C5D4ECDDEF80C4EC5A32CF8379541",
           "serverC": "61489C8AE69AA4B55AE296C98656751883F1F27C6D861019E9AAE9198EEFE4B6105DB0C7009A320DA52AFF699B816124CF986F8426AFFB48397054176A22EC46E81145ADEAB0B2D9C12725281115578D6A6FD8F8E605EDCC4DB6DC4068CB77E504C8529D248422E91ECF70A5F7CEDBB16EE3C503FF6E58C026228CAFB4F0A55B4C358665EA60A95522BEC50FA1538FAAC758EF7DB72A20B1E38C87C009D9C8A7D1D3F9999F465FD32C8A486C72D9407A9D136A6E68615F4EB3C6D463596DB867FC05EAED52B700EF4B7BF7D0005DBB9D30F57AA6CFBAC46E134E5E31BF106F0B38752A443C73CEF7D7C6C0C0B6A52F5E837A028196460068A0967E53E02FDE69"
         }
       ],
       "scheme": "KTS-OAEP-Party_V-confirmation",
       "kasRole": "responder",
       "keyGenerationMethod": "rsakpg2-basic",
       "modulo": 2048,
       "l": 512
       "iutId": "123456ABCD",
       "serverId": "434156536964",
       "ktsConfiguration": {
         "hashAlg": "SHA2-224",
         "associatedDataPattern": "",
         "encoding": "None"
       },
       "macConfiguration": {
         "macType": "KMAC-128",
         "keyLen": 128,
         "macLen": 224
       },
       "keyConfirmationDirection": "unilateral",
       "keyConfirmationRole": "provider"
     }
   ]
 }

]

@smuellerDD I am using this sample from https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ifc.txt. Even this case doesn't seem to succeed for me with OAEP decrypt. I am trying to figure out what could be going wrong. I could successfully encrypt-decrypt dummy data with same key given here

Kritner commented 3 years ago

The sample json in the specs are between separate samples are not necessarily tied to one another and valid together. You'll notice that the above test case "prompt file" specifies an l of 512, but the sample "result file" returns a key of only 384 bits - the two samples are not from the same test case, in this instance.

I'm not sure if that's where the confusion is coming in, but the best bet is to get a sample registration of vectors from the demo server itself.

nidhidamodaran commented 3 years ago

Thanks @Kritner . Verified with demo server samples

nidhidamodaran commented 3 years ago

quick question here, I hope there is no validation being done on the dkm value, and this dkm can be any random bytes of the specified size for initiator tests.

Kritner commented 3 years ago

quick question here, I hope there is no validation being done on the dkm value, and this dkm can be any random bytes of the specified size for initiator tests.

that's correct, what goes into the generation of the key that's wrapped is not within the scope of testing.