Hi Dieter Of course, given that one of these standards is a private standard that costs money to look at, does make this more challenging. But I imagine there are enough people in this group that have access to the standard that we should be able to discuss this. I ran this by some folks in my team that work on algorithm implementations, and this was the advice that came out of there: First, fix the CKD_SHA[224 256 384 512]_KDF description in 2.3.8 EC mechanism parameters, that is, change " The key derivation function CKD_NULL produces a raw shared secret value without applying any key derivation function whereas the key derivation function CKD_SHA1_KDF, which is based on SHA-1, derives keying data from the shared secret value as defined in ANSI X9.63." to " The key derivation function CKD_NULL produces a raw shared secret value without applying any key derivation function whereas the key derivation functions CKD_SHA[1 224 256 384 512]_KDF which are based on SHA-[1 224 256 384 512]derive keying data from the shared secret value as defined in ANSI X9.63." . Second, discuss whether introducing the NIST SP800-56A version of the these functions would be useful and if so, add those, too. E.g. adding the functions CKD_SHA[1 224 256 384 512]_NIST_KDF. Would you be able to discuss this further in our next TC meeting? If not, would someone else like to bring this issue up? It seems like something we should address in 2.41. Valerie On 6/9/2015 12:41 AM, Dieter Bong wrote: All, we encountered the following issue w.r.t key derivation functions for ECDH: ·NIST SP800-56A section 5.8.1.1 specifies the following for derivation of a key: Compute K(i) = H(counter Z OtherInfo) ·ANSI X9.63 in contrast specifies Ki = Hash(Z Counter [SharedInfo]) ANSI and NIST thus specify different orders for concatenation of ‘Z’ and ‘counter’. Has this been discussed in the TC before? The PKCS#11 standard explicitly references ANSI X.63 when using CKD_SHA1_KDF for derivation of keying data; there is no such explicit reference for CKD_SHA[224 256 384 512]_KDF. Yet I would assume they are also meant to be implemented according to ANSI X9.63. Is this assumption correct? One of our customers wants to implement key derivation according to NIST SP800-56A using PKCS#11 mechanism CKM_ECDH1_DERIVE. Strictly following the PKCS#11 standard this would not be possible resp. require implementation of a Vendor Defined Mechanism? Any thoughts or suggestion from your side? Thanks, Dieter Viele Grüße / With kind Regards Dieter Bong Product Manager HSM ** Utimaco IS GmbH Germanusstr. 4 DE-52080 Aachen Germany Fon: +49 241 1696 - 233 Mobil: +49 173 9080381 _www.utimaco.com <
http://www.utimaco.com/ >_ -------------------------------------------------------------------------------- Utimaco IS GmbH Seat: Aachen – Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO Wichtiger Hinweis: Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die E-Mail. Der Absender hat alle erdenklichen Vorsichtsmaßnahmen getroffen, dass die Anlagen dieser E-Mail frei von Computerviren o. Ä. sind. Gleichwohl schließen wir die Haftung für jeden Schaden aus, der durch Computerviren o. Ä. verursacht wurde, soweit wir nicht vorsätzlich oder grob fahrlässig gehandelt haben. Wir raten Ihnen, dass Sie in jedem Fall Ihre eigene Virenprüfung vornehmen, bevor Sie die Anlagen öffnen. Vielen Dank. Important Notice: The information contained in this email message may be confidential information. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email. We have taken every reasonable precaution to ensure that any attachment to this email has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Thank you for your cooperation. -- NOTE: Using voice recognition software, forgive typos/grammar mistakes! Valerie Fenwick,
http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.