RE: [pkcs11] Groups - Flexible KDF Draft 1 uploaded

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: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Dieter Bong
Sent: Wednesday, March 29, 2017 9:05 AM
To: Johnson Darren <darren.johnson@gemalto.com>; pkcs11@lists.oasis-open.org
Cc: Daniel Minder <Daniel.Minder@utimaco.com>
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' <darren.johnson@safenet-inc.com>; pkcs11@lists.oasis-open.org
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: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Darren Johnson
Sent: Montag, 13. März 2017 02:58
To: pkcs11@lists.oasis-open.org
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/

pkcs11 message