TDES CFB MCT Does Not Include PT/CT

[jk-acumen]

environment
Demo and Prod

testSessionId
Demo: 123075
Prod: 3034

vsId
Demo: 366026, 366027, 366028
Prod: 29625, 29626, 29627

Expected behavior
The MCT vectors for ACVP-TDES-CFB1, ACVP-TDES-CFB8 and ACVP-TDES-CFB64 did not include a PT/CT field. The description of the MCT says "the initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV, PT) set to some values" but the vectors only included key1, key2, key3 and iv.

For example, the vectors for ACVP-TDES-CFB1 on demo (vsid 366026):
{
"tgId": 13,
"direction": "Encrypt",
"testType": "MCT",
"keyingOption": 1,
"tests": [
{
"tcId": 689,
"key1": "C454B67C26341919",
"key2": "AB4FF1C110CD6B45",
"key3": "E5FB83CE0DFE405D",
"iv": "83C1D3365765C84F"
}
]
},
{
"tgId": 14,
"direction": "Decrypt",
"testType": "MCT",
"keyingOption": 1,
"tests": [
{
"tcId": 690,
"key1": "6145EF8354E5C449",
"key2": "A41A866BFDBC19C4",
"key3": "3DB362E3C49B15EF",
"iv": "46AA85EAAD1606AB"
}
]
}

[Kritner]

This is the result of a inconsistent casing check on our side. The valid values for this algorithm's "direction" property are "encrypt" and "decrypt", the problem registrations were done with "Encrypt" and "Decrypt".

We need to put in some checks to be more strict on what we're "allowing in the front door" at registration time regarding this string based properties.

[Kritner]

It should be noted that this is why guidance is given on ensuring integrations between the IUT and ACVP are working on the demo environment prior to moving to prod; the prod vector sets in the issue are not easily salvageable at this point.

I'll put in a correction for the next release that will ensure we're validating the case on these properties, but in the meantime you'll need to resubmit those vector sets with the appropriate "encrypt"/"decrypt".

[Kritner]

This change will be on demo from release v1.1.0.14 after the scheduled maintenance.

[Kritner]

This change is on production in release v1.1.0.14