Server rejects AES-XTS requests where data unit length does not match payload length

[jwesevic-atsec]

The ACVP server seems to reject any request in which an AES-XTS data unit length does not match the payload length, even when dataUnitLenMatchesPayload is set to false. The following message is returned:
[ {"acvVersion": "1.0"}, { "error": "Validation error(s) on JSON payload.", "context": [ "ACVP-AES-XTS-2.0: Unable to build test cases where multiple data units fit within one payload; this may be because the DataUnitLen and PayloadLen are overly restrictive" ] } ]

I've gotten this response to the following requests:

1. DataUnitLen = [512], PayloadLen = [256, 512]
2. DataUnitLen = [1024, 4096], PayloadLen = [65536] (this is the example found here for AES-XTS Testing Revision 2.0)

The full requests sent to the server are attached as Ex1.json and Ex2.json.

Ex1.json
Ex2.json

[livebe01]

Hi @jwesevic-atsec, we recently updated the behavior of the XTS 2.0 testing and must have forgotten to update the example. The example we use there is invalid and should be updated. @celic can you take a look at the XTS 2.0 example registration, prompt, and response to ensure they're all valid.

Also, @celic what are your thoughts on jwesevic-atsec's DataUnitLen = [512], PayloadLen = [256, 512] registration and the error it produces? @jwesevic-atsec does this registration match a real-world algorithm implementation that you wish to test?

[jwesevic-atsec]

Hi @livebe01, thanks for the quick reply and link to the recent changes. I guess that example might be a bit outdated, as it doesn't satisfy the previous assumption either.

Regarding example 1 I gave above, this registration does indeed match a real-world algorithm implementation that we wish to test. It should satisfy the requirements as listed in capabilities, in particular, the requirement that "all values for the payloadLen property MUST include all dataUnitLen values".

[celic]

Here is the condition we evaluate to determine a valid combination of the payloadLen and dataUnitLen...

There must exist at least one combination of p in payLoadLen and d in dataUnitLen such that d <= p and p % d >= 128.

While implementing XTS testing, I could not find the defined behavior in the standard for when the last data unit in a payload contains less than one full AES block, 127 bits or less. There are no restrictions on the size of the payload or the size of the data unit, so we did not want to impose any restrictions such as the payloadLens must be a strict multiple of the dataUnitLens.

The first example could be covered by a registration with dataUnitLenMatchesPayload: true with payloadLen = [256, 512]. A data unit length longer than a payload length does not make sense.

The second example seems like it should be valid. The data units always fit evenly in the payload, so there should be no issues on undefined behavior. I think we will need to update the above check to include...

p % d >= 128 OR p % d == 0

[sim-nvidia]

Wanted to chime in as the first case applies to us. We use XTS for DRAM encryption, not disk encryption. Hence, 512 bits is the size of a DRAM cacheline / block, which is our fundamental data unit. That is what we calculate the base tweak for. We can access the full (payload = 512 bits) or partial (payload = 256 bits) data unit.

This is why we would need tests for DataUnitLen = [512], PayloadLen = [256, 512]

[celic]

I'm a bit rusty with XTS. For a payload of 256 bits, the data unit length of 512 appears to have no impact on testing. It would only affect the algorithm if the data unit was less than the payload length. This could be tested with dataUnitLenMatchesPayload: true with payloadLen = [256, 512] even though that would not accurately list the capabilities on the algorithm certificate.

@sim-nvidia I have some general questions about XTS, if you couldn't mind reaching out over email (christopher.celi at nist.gov). For a very nuanced mode of AES, I don't have much insight on how it is typically implemented. If we make changes to our testing, getting a full idea of how the algorithm is used can help us set up these capabilities better.

[celic]

The fix for this will go into our next release. I don't think we have it scheduled yet though.

[livebe01]

The fix for this is on Demo in release v1.1.0.41.

[livebe01]

As of 11/12/25, the fix for this is on Prod in release v1.1.0.41.