ACVP-AES-XTS 2.0: server does not accept configured value for dataUnitLen (dataUnitLenMatchesPayload=false)

[locksmithone]

Demo server. "vsId": 674429

When registering a test for ACVP-AES-XTS 2.0, with dataUnitLenMatchesPayload=false and a set value for dataUnitLen, the demo server seemingly ignores the set value for dataUnitLen and generates testvectors with matching dataUnitLen and payloadLen.

Here is the registration POST operation:

[{"acvVersion":"1.0"},
{"isSample":true,"operation":"register","certificateRequest":"no","debugRequest":"yes","production":"no","encryptAtRest":"yes","algorithms":
  [{"revision":"2.0",
    "algorithm":"ACVP-AES-XTS",
    "direction": ["encrypt","decrypt"],
    "keyLen":[128,256],
    "payloadLen": [{"min":128,"max":65536,"increment":128}], 
    "tweakFormat":["duSequence"],
    "tweakMode":["number"],
    "dataUnitLen":[512],
    "dataUnitLenMatchesPayload":false}]
  }]

Here is a snippet of the test vector that is received from the demo server (with the corresponding vsId). Note the dataUnitLen and payloadLen values.

{
    "acvVersion": "1.0"
  },
  {
    "vsId": 674429,
    "algorithm": "ACVP-AES-XTS",
    "revision": "2.0",
    "isSample": true,
    "testGroups": [
      {
        "tgId": 1,
        "testType": "AFT",
        "direction": "encrypt",
        "keyLen": 128,
        "tweakMode": "number",
        "tests": [
          {
            "tcId": 1,
            "key": "67D418AE219DB1C4CD2B5CA1DE94A5780D0F371C3DD82C942F0E3ED1BFCE428F",
            "dataUnitLen": 896,
            "payloadLen": 896,
            "pt": "54D1A1048ABDE8A8E4D83005CCE91760827E9E82F4105C08D8A36B0A46959CFD31288BF5F428F6AB912C2D99E104379B1984675CCB74B7E0C7952C81697AD41272110A048530E4EADA6AF6ACF0239E0524D4851AA70F0E3C2C1025D913D11588D81EBC7F0A5C709E9F0E6BDAB0E4F0EC",
            "sequenceNumber": 161
          },
          {
            "tcId": 2,
            "key": "C790561CABD62FCA169D5654D9D0F7647A1DB5FC4107EC561ED436EEAC730ACD",
            "dataUnitLen": 34944,
            "payloadLen": 34944,
            "pt": "63ECE6563A57562D9E4CF1F5C2472691076E645981BF33AEE791730103CD160892199CFF61FFD2DE7736BC75B6D4E791D639BCC27B9CE6FFEC48560D35CD635AC1A8C9AAD9FCCBC431DFF667BE1FF73D9FA8CF6727D7B05BC375FC2CC304BD6D9D7A94AD11863AA5A1E49A2BF8A974E8751912F33B01D45655DA3114A26CA8CC0BEF1133086C57B19C0A68FC2E0636F48A9E996CD1C95CAFAE9C1A6838D6AF09E1C8322E9EFF860E85E4BC98B083F270436AEB517689953D1DB03
...

[Kritner]

@locksmithone the intention of the flag is to indicate that the IUT CAN support test cases where the payload and data unit length don't match. The testing still operates under the assumption that the IUT can process test can where the payload and data unit length do match.

• dataUnitLenMatchesPayload - means that all test groups the data unit length and payload length match
• !dataUnitLenMatchesPayload - means that some test groups will be created where the data unit length and payload don't match, but there will additionally be test groups where they do.

So it's not "one or the other", it's more "the data unit lengths not matching the payload length is an additional feature/capability of the IUT.

If you have a better way to convey this point into the specification feel free to put in a PR making the update.

[locksmithone]

In this case, what is the purpose of the dataUnitLen field? Whatever value we put there, the ACVP server may then generate test cases with that dataUnitLen, or any other value, as it happened in the testID provided.

On Thu, Aug 19, 2021 at 11:50 AM Russ Hammett @.***> wrote:

@locksmithone https://github.com/locksmithone the intention of the flag is to indicate that the IUT CAN support test cases where the payload and data unit length don't match. The testing still operates under the assumption that the IUT can process test can where the payload and data unit length do match.

• dataUnitLenMatchesPayload - means that all test groups the data unit length and payload length match
• !dataUnitLenMatchesPayload - means that some test groups will be created where the data unit length and payload don't match, but there will additionally be test groups where they do.

So it's not "one or the other", it's more "the data unit lengths not matching the payload length is an additional feature/capability of the IUT.

If you have a better way to convey this point into the specification feel free to put in a PR making the update.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/1224#issuecomment-902067500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKS6IRADD4S57VASY7DT5UXGDANCNFSM5CL6THSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[locksmithone]

I believe this issue is not closed? My original question referred to the server not obeying the domain set for dataUnitLen. As in the example I provided, dataUnitLenMatchesPayload=false, which of course admits that the dataUnitLen may or may not match the payload length. This is fine. But then we do specify values for dataUnitLen, which, in my understanding, would inform the server that "you may generate vectors that may or may not match the payload length, but will be restricted to the domain set in dataUnitLen". That was not the behavior, however: the server generated values for dataUnitLen outside of the domain registered. As such, setting a domain for dataUnitLen is useless.

[Kritner]

I'm not sure of the motivation behind the dataUnitLenMatchesPayload property, tagging @celic so hopefully he can elaborate. My current understanding is the the implementation MUST support when the data unit matches the payload. An additional "feature" of the implementation is that the implementation COULD also support instances where the data unit length DOES NOT match the payload - but the implementation still MUST be able to support tests where the data unit length matches the payload length.

The testing currently reflects the above statement. If the !dataUnitLenMatchesPayloadLen occurs, then we will test data unit lengths that DO NOT match the payload. Additionally, REGARDLESS of the dataUnitLenMatchesPayloadLen, we will have test cases that test against when the data unit len matches the payload len.

Just as an example, you'll get test cases like

dataUnitLenMatchesPayloadLen:

[{
  "dataUnitLen": 512,
  "payloadLen": 512,
}]

!dataUnitLenMatchesPayloadLen:

[
  {
    "dataUnitLen": 512,
    "payloadLen": 512,
  },
  {
    "dataUnitLen": 256,
    "payloadLen": 512
  }
]

Whether or not that was the intention of the dataUnitLenMatchesPayload property, I can't speak to, but hopefully @celic can shed some additional light on my current understanding.

[locksmithone]

Thank you. But that is not the main issue I am raising.

Let's forget dataUnitLenMatchesPayload. Let us focus only on dataUnitLen. There is only dataUnitLen in our universe now.

If the IUT registers as such:

...
"dataUnitLen":[256, 512],
...

is it OK for the ACVP server to send testvectors wherein dataUnitLen is 1024? Because if the IUT says it only supports dataUnitLen in the range [256, 512], does it HAVE to support dataUnitLen of 1024, which is outside of its registered range?

Or was the original issue caused by the IUT registering only one value for dataUnitLen, which implicitly tells the ACVP server that dataUnitLen must match the payload, since there is only one value being registered? Even if that is the case, should not the ACVP server at least obey the registered value for dataUnitLen?

[Kritner]

if a payload being tested is 1024 in length, then yes, a 1024 dataUnitLength can be sent in the prompt file regardless of the status of dataUnitLenMatchesPayload and the data unit length domain. We will be providing dataUnits matching both the payload length and the registered dataUnitLengths in instances of !dataUnitLenMatchesPayload.

This isn't an issue with the IUT's registration, nor the ACVP server as far as I can tell. The IUT MUST be able to test a payload "lengthed" data unit, regardless of the status of dataUnitLenMatchesPayload. It's not a great name for the property, but not sure what exactly else to call it.

The IUT MUST be able to work against payloads and data unit lengths that match. The IUT MAY support payload lengths that don't match the data unit length, and will utilize the registered domain of acceptable, non payload length matching data unit lengths.

[livebe01]

Thanks for persisting on this one @locksmithone! Hopefully this change to the definition of the dataUnitLen registration property helps.