[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [GRAYMAIL] [kmip] Groups - KMIP spec updates for GCM.pdf uploaded
Key Wrap Type |
4200F8 |
Batch Undo Capability |
4200F9 |
Batch Continue Capability |
4200FA |
PKCS#12 Friendly Name |
4200FB |
Description |
4200FC |
Comment |
4200FD |
Authenticated Encryption Additional Data |
4200FE |
Authenticated Encryption Tag |
4200FF |
Sorry I forgot to ask do we have real tag values for these two new attributes?
Best,Mark JosephP6R, IncMark,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/ ). 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.proposedmodes/gcm/gcm-revised- spec.pdf 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?BruceOn Fri, Aug 12, 2016 at 12:32 AM, Mark Joseph <mark@p6r.com> wrote:Hi BruceI went over your proposal and I have 2 comments:[1] The "Authenticated Encryption Additional Data" attributeI don't see this in the test case on any Encrypt or Decrypt commands in Tim's document.If we are going to add this attribute we really need to have a test case for it.[2] Also how do these new attributes work for streaming Encrypt / Decrypt usage?Do we need to add any text to your draft to explain that?Thanks,Mark JosephP6R, IncFrom: Bruce Rich <bar@cryptsoft.com>
To: <kmip@lists.oasis-open.org>
Sent: 8/11/2016 12:51 PM
Subject: [GRAYMAIL] [kmip] Groups - KMIP spec updates for GCM.pdf uploadedSubmitter's message
This is what seems an adequate mod to the KMIP1.3 spec to permit Authenticated Encryption and Decryption (with or without Additional Data). So AES-GCM, for example.
-- Mr. Bruce Rich
Document Name: KMIP spec updates for GCM.pdf
No description provided.
Download Latest Revision
Public Download Link
Submitter: Mr. Bruce Rich
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2016-08-11 12:50:50
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]