Mark,
Thanks for the questions. Here's a shot at the answers.
1) Yep. That test case had no additional data, was just showing tag creation and various validations (full-length tag, partial-length tag, invalid overly long tag). You have to get that right before tackling the complication of the additional data. The values were excised from test vectors from NIST (
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf). And we have almost two dozen others sourced the same way (and some to illustrate different tag lengths from gcmtestvectors.zip, file gcmDecrypt128.rsp). The intent was to illustrate and to whet your appetite for the others. We didn't want to just back up the truck and dump them on you. If you like, we can put another one out that has values for all the parameters.
2) Yep. Good question. There's nothing like posting a draft to open your eyes to what you should have seen BEFORE posting. After the call, I modified my draft to have the following in the Encrypt Request table...
|
Authenticated Encryption Additional Data, see 2.1.22
|
No
|
Any additional data to be authenticated via the Authenticated
Encryption Tag. If supplied in multi-part
encryption, this data MUST be supplied on the initial Encrypt request
|
And the following in the Decrypt Request table...
|
Authenticated Encryption Additional Data, see 2.1.22
|
No
|
Additional data to be authenticated via the Authenticated
Encryption Tag. If supplied in multi-part decryption, this data MUST be supplied
on the initial Decrypt request
|
|
Authenticated Encryption Tag, see 2.1.23
|
No
|
Specifies the tag that will be needed to authenticate the
decrypted data and the additional authenticated data. If supplied in multi-part decryption, this data
MUST be supplied on the initial Decrypt request
|
Does that address the issue adequately? Or did I just kick over another ant hill?
Bruce