Zero-length KWP keys should set 'invalid' result

[dspdon]

I noticed the KWP test vector file (kwp_test.json) has 3 test cases where key length (where key is 'key to be wrapped') is set to 0 and msg = ''. These cases are tcId 11, 86 and 171. I think these cases should be recorded with result set to 'invalid'. They currently have result set to 'acceptable'.

According to NIST SP 800-38F, length of the KWP key to be wrapped must be at least 1 byte. The language in SP 800-38F Sec 5.2 states this as: "KW-AE and TKW-AE are defined on two or more semiblocks. For KWP-AE, the domain of possible inputs is extended to nonempty octet strings." Wrapping a key with 0 length would be invalid.

[bleichenbacher-daniel]

The latest version of the test vectors in wycheproof/testvectors_v1/aes_kwp_test.json should be better.

[dspdon]

Thanks Daniel. I could use some insight: are the tests in the testvectors_v1 folder newer/better than those in the testvectors folder?

--Don

[bleichenbacher-daniel]

testvectors_v1 generally contains the latest version. The main difference is that the format for the flags has changed, so that it is possible to add more comments. The main purpose of the new flags was to describe what a test vector checks and to make a preliminary guess about the seriousness of the bug.

The main disadvantage of testvectors_v1 is that the documentation never has been updated for the new format.

[dspdon]

Thanks again Daniel. I'm now running the test cases in the "v1" folder. The KWP test cases in v1 all seem to be fine with regard to this setting --- no similar issues were found for the "result" enum values.

After reviewing the newer v1 format and folder, and noting your guidance for the "v0" folder, it still seems worth considering an update to the "result" enumeration for these three KWP test cases. Otherwise part of the KWP spec needs to be known and utilized in the test jig itself, to identify these test cases and override the result flag. You may know more about the impact of legacy use of the "v0" content however, so I'll leave it there.

Backing up slightly, I should have stated that the test cases in this repo are terrific and I'm definitely finding benefit from these. So some slightly belated thanks to everyone making these tests available.