Sample vector mismatch with real results vectors

[smuellerDD]

The following sample vectors provided from the /expected endpoint

• KW / KWP samples contain testPassed:true in each result although testPassed is only mandated for failing decryption

• TDES CFB64 MCT: The IV field results seem to be off-by-one for encryption (i.e. the right IV values are in the next MCT loop output). I just re-verified my MCT implementation with the ACVP server which provided passing verdicts.

ACVP server accepted data:

            "resultsArray":[
              {
                "key1":"48b61787cd394b9f",
                "key2":"34225a9bf5a7d247",
                "key3":"fa202aadacc137d9",
                "pt":"75f5a43e676ccfc5",
                "ct":"f927284ea75e4e9d",
                "iv":"f927284ea75e4e9d"
              },
              {
                "key1":"b0913ec86b670402",
                "key2":"a2f726bf51617043",
                "key3":"d38c5b465146949d",
                "pt":"97d57d24a4c6a204",
                "ct":"101c4e527572b80c",
                "iv":"101c4e527572b80c"
              },

Sample data:

      "resultsArray" : [ {
        "iv" : "1AC6CFD2C0522FE3",
        "pt" : "75F5A43E676CCFC5",
        "ct" : "F927284EA75E4E9D",
        "key1" : "48B61787CD394B9F",
        "key2" : "34225A9BF5A7D247",
        "key3" : "FA202AADACC137D9"
      }, {
        "iv" : "F927284EA75E4E9D",
        "pt" : "97D57D24A4C6A204",
        "ct" : "101C4E527572B80C",
        "key1" : "B0913EC86B670402",
        "key2" : "A2F726BF51617043",
        "key3" : "D38C5B465146949D"
      },

[locksmithone]

The "testPassed": true fields are included in expected responses in sample vectors for certain algorithms. The RFC draft only mandates the inclusion of testPassed: false if that is the case. The inclusion of the testPassed: true fields cause problems with JSON parsers that attempt to compare testPassed fields from response files (which are not expected to contain testPassed: true fields) with expected responses.

[Kritner]

@smuellerDD just to confirm from #870 (comment)

TDES CFB64 MCT: The IV field results seem to be off-by-one for encryption (i.e. the right IV values are in the next MCT loop output). I just re-verified my MCT implementation with the ACVP server which provided passing verdicts.

You're stating that your own results were sending in the incorrect values, that we were then passing? And yeah looking at this particular algorithm we were checking the result array values for key, pt, and ct, but not iv, so that's how you were getting a passing verdict. I'll make the update to this algorithm MCT validator and any others I find that might not be checking against the iv.

Additionally, I'll update the key wrapping algorithms so their result projection files only include the testPassed property when the test is a failing test.

[smuellerDD]

Am Dienstag, 1. September 2020, 17:53:50 CEST schrieb Russ Hammett: Hi Russ,

@smuellerDD just to confirm from #870 (comment) > TDES CFB64 MCT: The IV field results seem to be off-by-one for encryption > (i.e. the right IV values are in the next MCT loop output). I just > re-verified my MCT implementation with the ACVP server which provided > passing verdicts. You're stating that your own results were sending in the incorrect values, that we were then passing? And yeah looking at this particular algorithm we were checking the result array values for `key`, `pt`, and `ct`, but not `iv`, so that's how you were getting a passing verdict. I'll make the update to this algorithm MCT validator and any others I find that might not be checking against the `iv`. Additionally, I'll update the key wrapping algorithms so their result projection files only include the `testPassed` property when the test is a failing test.

I am saying that the sample vector provided by the ACVP server is off-by-one when comparing with my test results. As my test results are successfully validated by the server, I wonder whether the sample vector is wrong. But when you do not check the IV then also mine could be wrong. Are you now enforcing the validation of the IV? Ciao Stephan

[Kritner]

It's been a while since I've actually looked at the MCT implementations but your response looks a little suspect regarding the IVs:

"resultsArray":[
              {
                "key1":"48b61787cd394b9f",
                "key2":"34225a9bf5a7d247",
                "key3":"fa202aadacc137d9",
                "pt":"75f5a43e676ccfc5",
                "ct":"f927284ea75e4e9d",
                "iv":"f927284ea75e4e9d"
              },
              {
                "key1":"b0913ec86b670402",
                "key2":"a2f726bf51617043",
                "key3":"d38c5b465146949d",
                "pt":"97d57d24a4c6a204",
                "ct":"101c4e527572b80c",
                "iv":"101c4e527572b80c"
              },

IIRC the iv within the results array should be the starting iv, not the ending iv for that outer loop iteration. In the above your iv and ct would match each iteration through the loop currently.

The starting iv of an outer loop should be the last ct from the previous iteration through the inner loop, or the "seed" iv from the test case. I'll try to look a bit further into this tomorrow (gotta get started on dinner for the family) but wanted to get something out there as a response.

[smuellerDD]

confirmed - fixed on my side

[Kritner]

this change is now on production https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.12