GCM Test Vector Creation Failure

[awolf-bc]

environment DEMO

testSessionId 90938

vsId 238279

Algorithm registration

{
 "algorithms":[
    {
        "algorithm": "ACVP-AES-GCM",
        "revision": "1.0",
        "direction": [
            "encrypt",
            "decrypt"
        ],
        "keyLen": [
        128,
            192,
            256
        ],
    "payloadLen": [
            {
                "min": 8,
                "max": 65536,
                "increment": 8
            }
    ],
    "ivGen": "external",
    "ivGenMode": "8.2.1",
    "ivLen": [
            {
                "min": 8,
                "max": 1024,
                "increment": 8
            }
    ],
    "aadLen": [
            {
                "min": 8,
                "max": 65536,
                "increment": 8
            }
    ],
    "tagLen": [
            32,
            64,
            96,
            104,
            112,
            120,
            128
        ]
    }
 ]
}

Endpoint in which the error is experienced https://acvp/v1/testSessions/90938/vectorSets/238279 GET

Expected behavior The test vector data should be returned. Instead I see an "internal error message":

[ {
...
}, {
    "error": "General exception. Contact service provider."
} ]

[celic]

I'll take a look at this. Nothing jumps out as improper with the registration, and if anything was, this error would be more descriptive.

[awolf-bc]

I took the values from the related RFC document. This test is the first time the 'full combinatorical size' is used in the registration. Previously, some of the values were smaller 'subsets'. Maybe a resource limit?

[celic]

I've tracked down the error, but this is a bit complex to fix.

One thing we've considered of late is reducing the combinatorial nature of GCM testing. The same assurances can be acquired from using a couple random combinations of parameters, ensuring all values are hit rather than all combinations are hit. This would help file sizes for one of our most frequently tested algorithms as well. A registration like this might be the tipping point.

[awolf-bc]

Sounds fair. What parameter would you recommend should be reduced?

[celic]

If you would still like all the data, I'd separate the vector sets out by the key length. Otherwise the size 65536 is very large and can be reduced.

[awolf-bc]

Yes, the key length is a sensible choice. I will separate this into 3 registrations and retry.

[awolf-bc]

Reducing "combinatoric size" fixes this issue. Maybe a different/better error handling on resource limits can be employed?

[celic]

We have a fix for this coming in the next release in general. Expect smaller GCM files to be produced. They should still cover all registered options, including min, max and several special cases such as block size and non-block size. Instead of using a combinatoric approach, values will be randomly grouped together. Rather than producing 100+MB JSON files, we are looking at around 15MB.

[celic]

Fixed with patch today.