usnistgov / ACVP-Server

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

TDES: two key TDES - testable or not? #161

Open smuellerDD opened 2 years ago

smuellerDD commented 2 years ago

https://github.com/usnistgov/ACVP/blob/master/src/symmetric/sections/05-capabilities.adoc#block-cipher-algorithm-capabilities-json-values states:

"The Keying Option used in TDES. Keying option 1 (1) is 3 distinct keys (K1, K2, K3). Keying Option 2 (2) is 2 distinct keys only suitable for decrypt (K1, K2, K1)."

I vaguely remember that Chris stated that anything but 3key TDES is not testable any more. But 2key TDES is a legacy algorithm and I would expect it being testable.

Now I tried to obtain 2key TDES for which I only partially got the right vectors.

Example for a 2key TDES vector:

    "algorithm": "CMAC-TDES",
    "revision": "1.0",
    "isSample": false,
    "testGroups": [
      {
        "tgId": 1,
        "testType": "AFT",
        "direction": "ver",
        "msgLen": 64,
        "macLen": 64,
        "tests": [
          {
            "tcId": 1,
            "key": "E59102B0164A4683832F04B92CF867ECE59102B0164A4683",
            "message": "CF63957F5A7B0E7D",
            "mac": "45F22CBE0CAF9185",
            "key1": "E59102B0164A4683",
            "key2": "832F04B92CF867EC",
            "key3": "E59102B0164A4683"
          },
          {
            "tcId": 2,
            "key": "A70D98DFCE98BACDD3AB57FBA773684AA70D98DFCE98BACD",
            "message": "BFD2029A3B66EEC8",
            "mac": "29455778739DC141",
            "key1": "A70D98DFCE98BACD",
            "key2": "D3AB57FBA773684A",
            "key3": "A70D98DFCE98BACD"
          },

Example for TDES vector that is not 2key albeit being queried for:

    "algorithm": "ACVP-TDES-CFB64",
    "revision": "1.0",
    "isSample": false,
    "testGroups": [
      {
        "tgId": 1,
        "direction": "encrypt",
        "testType": "AFT",
        "keyingOption": 1,
        "tests": [
          {
            "tcId": 1,
            "key1": "1046913489980131",
            "key2": "0101010101010101",
            "key3": "1007103489988020",
            "pt": "0000000000000000",
            "iv": "0000000000000000"
          },
          {
            "tcId": 2,
            "key1": "10071034C8980120",
            "key2": "0101010101010101",
            "key3": "1046103489988020",
            "pt": "0000000000000000",
            "iv": "0000000000000000"
          },

Here is the query for the latter vector:

      {
        "revision":"1.0",
        "algorithm":"ACVP-TDES-CFB64",
        "direction":[
          "encrypt",
          "decrypt"
        ],
        "keyLen":[
          168
        ],
        "payloadLen":[
          {
            "min":64,
            "max":65536,
            "increment":64
          }
        ],
        "ivLen":[
          64
        ],
        "keyingOption":[
          2
        ]
      },

Thus, could you please help me clarify what TDES option is supported?

Thanks

livebe01 commented 2 years ago

Hi @smuellerDD, sure. As you quoted from the symmetric spec, "Keying Option 2 (2) is 2 distinct keys only suitable for decrypt (K1, K2, K1)." Similarly, the MAC spec states, "Keying Option 2 (2) is 2 distinct only suitable for decrypt (K1, K2, K1)." The source of these requirements can be found in SP 800-131Ar2 Section 2.

Nothing seems amiss w/ the first example you provided. For the second example, it looks like we have an issue in our logic somewhere. You shouldn't be receiving keyingOption 1 vectors when your capabilities registration only advertises keyingOption 2. I'm not sure if the correct behavior is to reject the registration because "direction": ["encrypt"] is disallowed with keyingOption 2 or if it should be allowed and no "direction": ["encrypt"] vectors should be returned. I'll look into what the correct thing to do is and get a fix out.

celic commented 2 years ago

As a heads up, keyLen and ivLen are not valid TDES registration properties. They can be removed. payloadLen as well for this particular mode, is not supported. For most TDES modes, the only properties should be direction and keyingOption.

keyLen is only valid for TDES-KW.

I do recall working with you @smuellerDD on TDES 2-key KATs. These particular tests you're getting with 3 keys are staticly generated KATs. Do you happen to remember if that was over email or a separate issue on this repository?

smuellerDD commented 2 years ago

Am Freitag, 19. November 2021, 16:52:50 CET schrieb Chris Celi:

Hi Chris,

As a heads up, keyLen and ivLen are not valid TDES registration properties. They can be removed. payloadLen as well for this particular mode, is not supported. For most TDES modes, the only properties should be direction and keyingOption.

keyLen is only valid for TDES-KW.

I do recall working with you @smuellerDD on TDES 2-key KATs. These particular tests you're getting with 3 keys are staticly generated KATs. Do you happen to remember if that was over email or a separate issue on this repository?

Unfortunately I do not recall.

Ciao Stephan