ACVP
ACVP copied to clipboard
usnistgov
XTS testvectors have empty tgId tests
Protocol Section AES-XTS: https://pages.nist.gov/ACVP/draft-celi-acvp-symmetric.html
Protocol Question Testvector request has apparently empty test instances. Expected responses for the respective empty tests show empty responses. Testvectors obtained several months apart show the same behavior.
Question: Is this behavior a bug, or is it normal behavior?
Example
Testvector request (see tgId: 2):
[
{
"acvVersion": "1.0"
},
{
"vsId": 676697,
"algorithm": "ACVP-AES-XTS",
"revision": "2.0",
"isSample": true,
"testGroups": [
{
"tgId": 1,
"testType": "AFT",
"direction": "encrypt",
"keyLen": 128,
"tweakMode": "number",
"tests": [
{
"tcId": 1,
"key": "9D0F425AF31724C5C4A7930F679E1425562914748EFB84879BD14D7FC85F0F8B",
"dataUnitLen": 512,
"payloadLen": 512,
"pt": "9A36FBCD8DDE25CDE096443F37DC81068B106E5590AEEB98DDCF3819E5055C08E6CAECE9A49F36C57EA5237A936157D4EA33842568F656871F9F6DC3A4A47303",
"sequenceNumber": 234
},
{
"tcId": 2,
"key": "AFB8A087B8C9575F483E948C78DCB5D48BF10CF5CCED1EAAF65EE2F4400688B0",
"dataUnitLen": 512,
"payloadLen": 512,
"pt": "1E6BA14D5B53A42B8813100C0CC34F836C04168981FA1A5106FBDA5DF4DF72594AA14FC75F22D9A17A8DF0E73F24A6D0BCD7D4B35FD3516D32016F34F41FB979",
"sequenceNumber": 41
}
]
},
{
"tgId": 2,
"testType": "AFT",
"direction": "encrypt",
"keyLen": 128,
"tweakMode": "number",
"tests": []
},
{
Expected response:
[
{
"acvVersion": "1.0"
},
{
"vsId": 676697,
"algorithm": "ACVP-AES-XTS",
"revision": "2.0",
"isSample": true,
"testGroups": [
{
"tgId": 1,
"tests": [
{
"tcId": 1,
"ct": "413C713AF1E0345B734EE3570EA220C1029CE2AA018F42448FB7A57D411F58A609B33C83E26B638252A15EA923E0E41BA500F2F17ACBDF2294B37BC66C53B665"
},
{
"tcId": 2,
"ct": "EBB7A6F1146CDD2047EA45D291B8B381BB944899749F9C8CFA9CC51E1002C7600F31B473520300CFCDF464AFAA3F5606F77AC3B0009DC30C6C2D755D26573FAC"
}
]
},
{
"tgId": 2,
"tests": []
},
{
Hi @locksmithone, can you share the capabilities registration for 676697? It looks like that vector set is expired and we can't see the info for it on our end. Thanks!
Absolutely. Here it is.
[
{
"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":[
512
],
"tweakFormat":[
"duSequence"
],
"tweakMode":[
"number"
],
"dataUnitLen":[
512
],
"dataUnitLenMatchesPayload":false
}
]
}
]
Guessing it's a miss in the validator around the condition of having !dataUnitLenMatchesPayload, but registering capabilities where the dataUnitLen and payloadLen only have matching values.
Hmm. Would that be a bug, or by design?
To give some context of why this registration contains dataUnitLengthMatchesPayload=false, but still the dataUnitLen and the payloadLen are the same, the result came about on the issue here: #1224 .
In that #1224 original registration, the payloadLen had a range, but the dataUnitLen was fixed at one value, because that data unit length was the only one supported by the module. Still, the ACVP server would generate testvectors with data units of any lengths, making those vectors impossible to be processed by the IUT. As the issue was not resolved, the workaround was to set the payloadLen to the same length as the data unit, so that the data unit length would then not ever vary anymore.
I think the answer is that this is a bug. We'll dig into this/get this sorted.
Hi @locksmithone, I'm going to tackle this moving forward, thanks for your patience.
@jbrock24 it could be worth trying the registration in question against Demo again to see if the behavior still presents as there were a number of updates to XTS 2.0 in release v1.1.0.25.
For precisely that same registration, here is the error the server gives:
ACVPProxy (10:33:20) (tid0) Error: Server error response: [
{
"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"
]
}
]
Ah, have you tried this registration with "dataUnitLenMatchesPayload":true? I see that the dataUnitLen matches the payloadLen in this instance.
I have not... I suppose it does not cause the version of XTS to revert to 1.0?
On Tue, Nov 8, 2022 at 7:59 AM livebe01 @.***> wrote:
Ah, have you tried this registration with "dataUnitLenMatchesPayload":true? I see that the dataUnitLen matches the payloadLen in this instance.
— Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/1350#issuecomment-1307263127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKTFUN7523YHWKPHNODWHJMEFANCNFSM52C7WH6A . You are receiving this because you were mentioned.Message ID: @.***>
Ah, setting dataUnitLenMatchesPayloadLen to true doesn't literally cause the 1.0 code to be accessed. But setting dataUnitLenMatchesPayloadLen to true is roughly equivalent to getting a vector set from the 1.0 code. If dataUnitLenMatchesPayloadLen is set to true, for each test case provided, the dataUnitLen will equal the payloadLen.
Ah. I did run a few new registrations with "dataUnitLenMatchesPayload":true, and I do not see empty tests anymore. Moreover, now the dataUnit and payload lengths do match, as opposed to in the past wherein they would not, even though the parameter was marked as true.
I believe that solves the issue, thank you.
MP
On Tue, Nov 8, 2022 at 1:32 PM livebe01 @.***> wrote:
Ah, setting dataUnitLenMatchesPayloadLen to true doesn't literally cause the 1.0 code to be accessed. But setting dataUnitLenMatchesPayloadLen to true is roughly equivalent to getting a vector set from the 1.0 code. If dataUnitLenMatchesPayloadLen is set to true, for each test case provided, the dataUnitLen will equal the payloadLen.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Message ID: @.***>