Hi Deiter,
Good points.
I have to admit I did not study those KDF modes that closely yet. I will do so and hopefully be able to address Daniel’s concerns.
I will also be making one other change to the overall mechanism structure. I will be removing the CK_FKDF_HANDLE type out of the array of data types and adding
an array of “additional input” handles to the top level mechanism parameter structure. This is so that all input keys can be combined using a specified hash mechanism so that the overall structure of the KDF is consistent with SP800-108… specifically the
KDF should use the base key (or the result of the combined base keys) as the input key for the PRF, and all data parameters are treated as “data” parameters to the PRF.
This should eliminate any theoretical debates on leaking information input keys because why proposal uses the additional base keys differently then SP800-108.
After today’s call, I will update and recirculate the proposal.
Thanks
Darren
From: [mailto:]
On Behalf Of Dieter Bong
Sent: Wednesday, March 29, 2017 9:05 AM
To: Johnson Darren <>;
Cc: Daniel Minder <>
Subject: RE: [pkcs11] Groups - Flexible KDF Draft 1 uploaded
Hi Darren,
I add some additional comments from my new PM colleague Daniel:
For the Feedback Mode and Double-Pipeline Iteration Mode acc to SP800-108, additional input is needed.
The Feedback Mode expects an additional IV, which has to be specified explicitly.
In the Double-Pipeline Iteration Mode, the IV is defined as: Label || 0x00 || Context || [L]2. Although the input for the KDF is: A(i) {|| [i]2} || Label || 0x00 || Context || [L]2, we cannot just remove the first counter from the CK_FKDF_DATA_PARAM
(if present) to create the IV implicitly. Thus, the IV must be passed explicitly although this is cumbersome for the user since the IV needs to be concatenated manually.
Therefore, an IV field needs to be added to CK_FKDF_PARAMS (which can be NULL or is ignored for some KDFs).
Best regards,
Dieter
From: Dieter Bong
Sent: Dienstag, 28. März 2017 16:32
To: 'Darren Johnson' <>;
Subject: RE: [pkcs11] Groups - Flexible KDF Draft 1 uploaded
Hi Darren,
that’s an interesting proposal. I have included a few minor comments and questions in the document itself, please check the track changes and comments. The most important question
for me is: When passing (a pointer to) a CK_FKDF_COUNTER_PARAM structure, is C_Derive supposed to increment that counter after using for key derivation? Or is the application supposed to increment the counter after C_Derive has returned? Please clarify.
Thanks,
Dieter
From:
[mailto:]
On Behalf Of Darren Johnson
Sent: Montag, 13. März 2017 02:58
To:
Subject: [pkcs11] Groups - Flexible KDF Draft 1 uploaded
Submitter's message
The Flexible KDF proposal draft 1 is uploaded and ready for initial review.
This proposal was originally written for use outside of this TC. As such, it is written in a format/style that is not consistent with the PKCS#11 standard.
-- Mr. Darren Johnson
Document Name:
Flexible KDF Draft 1
Description
A proposal for a new symmetric key derivation mechanism.
Download Latest Revision
Public Download Link
Submitter: Mr. Darren Johnson
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2017-03-12 18:57:48
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0,
www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
This communication is confidential. We only send and receive email on the basis of the terms set out at
https://www.utimaco.com/en/e-mail-disclaimer/
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized
use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
