| < draft-krawczyk-hkdf-00.txt | draft-krawczyk-hkdf-01.txt > | |||
|---|---|---|---|---|
| Network Working Group H. Krawczyk | Network Working Group H. Krawczyk | |||
| Internet-Draft IBM Research | Internet-Draft IBM Research | |||
| Intended status: Informational P. Eronen | Intended status: Informational P. Eronen | |||
| Expires: December 19, 2009 Nokia | Expires: July 29, 2010 Nokia | |||
| June 17, 2009 | January 25, 2010 | |||
| HMAC-based Extract-and-Expand Key Derivation Function (HKDF) | HMAC-based Extract-and-Expand Key Derivation Function (HKDF) | |||
| draft-krawczyk-hkdf-00.txt | draft-krawczyk-hkdf-01.txt | |||
| Abstract | ||||
| This document specifies a simple HMAC-based key derivation function | ||||
| (HKDF) which can be used as a building block in various protocols and | ||||
| applications. The KDF is intended to support a wide range of | ||||
| applications and requirements, and is conservative in its use of | ||||
| cryptographic hash functions. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 41 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on December 19, 2009. | This Internet-Draft will expire on July 29, 2010. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
| publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | ||||
| Abstract | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | ||||
| This document specifies a simple HMAC-based key derivation function | described in the BSD License. | |||
| (HKDF) which can be used as a building block in various protocols and | ||||
| applications. The KDF is intended to support a wide range of | ||||
| applications and requirements, and is conservative in its use of | ||||
| cryptographic hash functions. | ||||
| 1. Introduction | 1. Introduction | |||
| A key derivation function (KDF) is a basic and essential component of | A key derivation function (KDF) is a basic and essential component of | |||
| cryptographic systems. Its goal is to take some source of initial | cryptographic systems. Its goal is to take some source of initial | |||
| keying material, and derive from it one or more cryptographically | keying material and derive from it one or more cryptographically | |||
| strong secret keys. | strong secret keys. | |||
| This document specifies a simple HMAC-based [HMAC] KDF, named HKDF, | This document specifies a simple HMAC-based [HMAC] KDF, named HKDF, | |||
| which can be used as a building block in various protocols and | which can be used as a building block in various protocols and | |||
| applications, and is already used in several IETF protocols, | applications, and is already used in several IETF protocols, | |||
| including [IKEv2], [PANA], and [EAP-AKA]. | including [IKEv2], [PANA], and [EAP-AKA]. The purpose is to document | |||
| this KDF in a general way to facilitate adoption in future protocols | ||||
| and applications, and to discourage the proliferation of multiple KDF | ||||
| mechanisms. It is not intended as a call to change existing | ||||
| protocols. | ||||
| HKDF follows the "extract-then-expand" paradigm where the KDF | HKDF follows the "extract-then-expand" paradigm where the KDF | |||
| logically consists of two modules. The first stage takes the input | logically consists of two modules. The first stage takes the input | |||
| keying material and "extracts" from it a fixed-length pseudorandom | keying material and "extracts" from it a fixed-length pseudorandom | |||
| key K. The second stage "expands" the key K into several additional | key K. The second stage "expands" the key K into several additional | |||
| pseudorandom keys (the output of the KDF). | pseudorandom keys (the output of the KDF). | |||
| In many applications, the input keying material is not necessarily | In many applications, the input keying material is not necessarily | |||
| distributed uniformly, and the attacker may have some partial | distributed uniformly, and the attacker may have some partial | |||
| knowledge about it (for example, a Diffie-Hellman value computed by a | knowledge about it (for example, a Diffie-Hellman value computed by a | |||
| skipping to change at page 4, line 13 ¶ | skipping to change at page 4, line 13 ¶ | |||
| PRK = HMAC-Hash(salt, IKM) | PRK = HMAC-Hash(salt, IKM) | |||
| 2.3. Step 2: Expand | 2.3. Step 2: Expand | |||
| OKM = HKDF-Expand(PRK, info, L) | OKM = HKDF-Expand(PRK, info, L) | |||
| Options: | Options: | |||
| Hash a hash function; HashLen denotes the length of the | Hash a hash function; HashLen denotes the length of the | |||
| hash function output in octets | hash function output in octets | |||
| Inputs: | Inputs: | |||
| PRK a pseudo-random key of HashLen octets | PRK a pseudo-random key of at least HashLen octets | |||
| (usually, the output from the Extract step) | (usually, the output from the Extract step) | |||
| info optional context and application specific information | info optional context and application specific information | |||
| (can be a zero-length string) | (can be a zero-length string) | |||
| L length of output keying material in octets | L length of output keying material in octets | |||
| (<= 255*HashLen) | (<= 255*HashLen) | |||
| Output: | Output: | |||
| OKM output keying material (of L octets) | OKM output keying material (of L octets) | |||
| The output OKM is calculated as follows: | The output OKM is calculated as follows: | |||
| skipping to change at page 4, line 47 ¶ | skipping to change at page 4, line 47 ¶ | |||
| 3. Notes to HKDF Users | 3. Notes to HKDF Users | |||
| This section contains a set of guiding principles regarding the use | This section contains a set of guiding principles regarding the use | |||
| of HKDF. A much more extensive account of such principles and design | of HKDF. A much more extensive account of such principles and design | |||
| rationale can be found in [HKDF-paper]. | rationale can be found in [HKDF-paper]. | |||
| 3.1. To Salt or not to Salt | 3.1. To Salt or not to Salt | |||
| HKDF is defined to operate with and without random salt. This is | HKDF is defined to operate with and without random salt. This is | |||
| done to accommodate applications where a salt value is not available, | done to accommodate applications where a salt value is not available. | |||
| We stress, however, that the use of salt adds significantly to the | We stress, however, that the use of salt adds significantly to the | |||
| strength of HKDF, ensuring independence between different uses of the | strength of HKDF, ensuring independence between different uses of the | |||
| hash function, supporting "source-independent" extraction, and | hash function, supporting "source-independent" extraction, and | |||
| strengthening the analytical results that back the HKDF design. | strengthening the analytical results that back the HKDF design. | |||
| Random salt differs fundamentally from the initial keying material in | Random salt differs fundamentally from the initial keying material in | |||
| two ways: it is non-secret and can be re-used. As such, salt values | two ways: it is non-secret and can be re-used. As such, salt values | |||
| are available to many applications. For example, a PRNG that | are available to many applications. For example, a PRNG that | |||
| continuously produces outputs by applying HKDF to renewable pools of | continuously produces outputs by applying HKDF to renewable pools of | |||
| entropy (e.g., sampled system events) can fix a salt value and use it | entropy (e.g., sampled system events) can fix a salt value and use it | |||
| for multiple applications of HKDF without having to protect the | for multiple applications of HKDF without having to protect the | |||
| secrecy of the salt. In a different application domain, a key | secrecy of the salt. In a different application domain, a key | |||
| agreement protocol deriving cryptographic keys from a Diffie-Hellman | agreement protocol deriving cryptographic keys from a Diffie-Hellman | |||
| exchange can derive a salt value from public nonces exchanged between | exchange can derive a salt value from public nonces exchanged and | |||
| communicating parties as part of the key agreement (this is the | authenticated between communicating parties as part of the key | |||
| approach taken in [IKEv2]). | agreement (this is the approach taken in [IKEv2]). | |||
| Ideally, the salt value is a random (or pseudorandom) string of the | Ideally, the salt value is a random (or pseudorandom) string of the | |||
| length HashLen. Yet, even a salt value of less quality (shorter in | length HashLen. Yet, even a salt value of less quality (shorter in | |||
| size or with limited entropy) may still make a significant | size or with limited entropy) may still make a significant | |||
| contribution to the security of the output keying material; designers | contribution to the security of the output keying material; designers | |||
| of applications are therefore encouraged to provide salt values to | of applications are therefore encouraged to provide salt values to | |||
| HKDF if such values can be obtained by the application. | HKDF if such values can be obtained by the application. | |||
| It is worth noting that, while not the typical case, some | It is worth noting that, while not the typical case, some | |||
| applications may even have a secret salt value available for use; in | applications may even have a secret salt value available for use; in | |||
| skipping to change at page 6, line 37 ¶ | skipping to change at page 6, line 37 ¶ | |||
| keying material (IKM) comes from some source modeled as a probability | keying material (IKM) comes from some source modeled as a probability | |||
| distribution over bit streams of a certain length (e.g., streams | distribution over bit streams of a certain length (e.g., streams | |||
| produced by an entropy pool, values derived from Diffie-Hellman | produced by an entropy pool, values derived from Diffie-Hellman | |||
| exponents chosen at random, etc.); each instance of IKM is a sample | exponents chosen at random, etc.); each instance of IKM is a sample | |||
| from that distribution. A major goal of key derivation functions is | from that distribution. A major goal of key derivation functions is | |||
| to ensure that when applying the KDF to any two values IKM and IKM' | to ensure that when applying the KDF to any two values IKM and IKM' | |||
| sampled from the (same) source distribution, the resultant keys OKM | sampled from the (same) source distribution, the resultant keys OKM | |||
| and OKM' are essentially independent of each other (in a statistical | and OKM' are essentially independent of each other (in a statistical | |||
| or computational sense). To achieve this goal it is important that | or computational sense). To achieve this goal it is important that | |||
| inputs to KDF are selected from appropriate input distributions and | inputs to KDF are selected from appropriate input distributions and | |||
| also that these inputs are chosen independent of each other | also that inputs are chosen independent of each other (technically, | |||
| (technically, it is necessary that each sample will have sufficient | it is necessary that each sample will have sufficient entropy even | |||
| entropy even when conditioned on other inputs to KDF). | when conditioned on other inputs to KDF). | |||
| Independence is also an important aspect of the salt value provided | Independence is also an important aspect of the salt value provided | |||
| to a KDF. While there is no need to keep the salt secret, and the | to a KDF. While there is no need to keep the salt secret, and the | |||
| same salt value can be used with multiple IKM values, it is assumed | same salt value can be used with multiple IKM values, it is assumed | |||
| that salt values are independent of the input keying material. In | that salt values are independent of the input keying material. In | |||
| particular, an application needs to make sure that salt values are | particular, an application needs to make sure that salt values are | |||
| not chosen or manipulated by an attacker. As an example, consider | not chosen or manipulated by an attacker. As an example, consider | |||
| the case (as in IKE) where the salt is derived from nonces supplied | the case (as in IKE) where the salt is derived from nonces supplied | |||
| by the parties during a key exchange protocol. Before the protocol | by the parties during a key exchange protocol. Before the protocol | |||
| can use such salt to derive keys, it needs to make sure that these | can use such salt to derive keys, it needs to make sure that these | |||
| skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 25 ¶ | |||
| agreement protocol; derivation of symmetric keys from a hybrid | agreement protocol; derivation of symmetric keys from a hybrid | |||
| public-key encryption scheme; key derivation for key-wrapping | public-key encryption scheme; key derivation for key-wrapping | |||
| mechanisms; and more. All of these applications can benefit from the | mechanisms; and more. All of these applications can benefit from the | |||
| simplicity and multi-purpose nature of HKDF, as well as from its | simplicity and multi-purpose nature of HKDF, as well as from its | |||
| analytical foundation. | analytical foundation. | |||
| On the other hand, it is anticipated that some applications will not | On the other hand, it is anticipated that some applications will not | |||
| be able to use HKDF "as-is" due to specific operational requirements, | be able to use HKDF "as-is" due to specific operational requirements, | |||
| or will be able to use it but without the full benefits of the | or will be able to use it but without the full benefits of the | |||
| scheme. One significant example is the derivation of cryptographic | scheme. One significant example is the derivation of cryptographic | |||
| keys from a source of low entropy such as a user's password. The | keys from a source of low entropy, such as a user's password. The | |||
| extract step in HKDF can concentrate existing entropy but cannot | extract step in HKDF can concentrate existing entropy but cannot | |||
| amplify entropy. In the case of password-based KDFs (PBKDF), a main | amplify entropy. In the case of password-based KDFs, a main goal is | |||
| goal is to slow down dictionary attacks using two ingredients: a salt | to slow down dictionary attacks using two ingredients: a salt value | |||
| value and the intentional slowing of the key derivation computation. | and the intentional slowing of the key derivation computation. HKDF | |||
| HKDF naturally accommodates the use of salt; however, slowing down | naturally accommodates the use of salt; however, a slowing down | |||
| computation is not part of its specification (obviously, this would | mechanism is not part of this specification. Applications interested | |||
| be a wasteful design for most KDF applications). Therefore, PBKDF | in a password-based KDF should consider whether, for example, [PKCS5] | |||
| applications interested in adapting HKDF to their setting can either | meets their needs better than HKDF. | |||
| replace the extract step with an intentional slow-down mechanism | ||||
| (e.g., applying repeated hashing) or can use both the extract and | ||||
| expand mechanism of HKDF with a slowing-down mechanism applied after | ||||
| the extract step and before expansion. | ||||
| 5. Security Considerations | 5. Security Considerations | |||
| In spite of the simplicity of HKDF there are many security | In spite of the simplicity of HKDF there are many security | |||
| considerations that have been taken in the design and analysis of | considerations that have been taken in the design and analysis of | |||
| this construction. An exposition of all these aspects is beyond the | this construction. An exposition of all these aspects is beyond the | |||
| scope of this document. Please refer to [HKDF-paper] for detailed | scope of this document. Please refer to [HKDF-paper] for detailed | |||
| information, including rationale for the design and for the | information, including rationale for the design and for the | |||
| guidelines presented in Section 3. | guidelines presented in Section 3. | |||
| A major effort has been made in the above paper to provide a | A major effort has been made in the above paper to provide a | |||
| cryptographic analysis of HKDF as a multi-purpose KDF that exercises | cryptographic analysis of HKDF as a multi-purpose KDF that exercises | |||
| much care in the way it utilizes cryptographic hash functions. This | much care in the way it utilizes cryptographic hash functions. This | |||
| is particularly important due to the limited confidence we have in | is particularly important due to the limited confidence we have in | |||
| the strength of current hash functions. This analysis, however, does | the strength of current hash functions. This analysis, however, does | |||
| not imply the absolute security of any scheme and depends heavily on | not imply the absolute security of any scheme and it depends heavily | |||
| modeling choices. Yet, it serves as a strong indication of the | on the strength of the underlying hash function and on modeling | |||
| correct structure of the HKDF design and its advantages over other | choices. Yet, it serves as a strong indication of the correct | |||
| common KDF schemes. | structure of the HKDF design and its advantages over other common KDF | |||
| schemes. | ||||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 7. Acknowledgments | 7. Acknowledgments | |||
| (To be added.) | The authors would like to thank members of the CFRG (Crypto Forum | |||
| Research Group) list for their useful comments, and to Dan Harkins | ||||
| for providing test vectors. | ||||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
| Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
| February 1997. | February 1997. | |||
| [KEYWORDS] | [KEYWORDS] | |||
| skipping to change at page 9, line 4 ¶ | skipping to change at page 8, line 48 ¶ | |||
| Amendment 1: Additional Techniques", IEEE Std 1363a-2004, | Amendment 1: Additional Techniques", IEEE Std 1363a-2004, | |||
| 2004. | 2004. | |||
| [800-108] National Institute of Standards and Technology, | [800-108] National Institute of Standards and Technology, | |||
| "Recommendation for Key Derivation Using Pseudorandom | "Recommendation for Key Derivation Using Pseudorandom | |||
| Functions", NIST Special Publication 800-108, | Functions", NIST Special Publication 800-108, | |||
| November 2008. | November 2008. | |||
| [800-56A] National Institute of Standards and Technology, | [800-56A] National Institute of Standards and Technology, | |||
| "Recommendation for Pair-Wise Key Establishment Schemes | "Recommendation for Pair-Wise Key Establishment Schemes | |||
| Using Discrete Logarithm Cryptography", NIST Special | Using Discrete Logarithm Cryptography (Revised)", NIST | |||
| Publication 800-56A, March 2006. | Special Publication 800-56A, March 2007. | |||
| [EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved | [EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved | |||
| Extensible Authentication Protocol Method for 3rd | Extensible Authentication Protocol Method for 3rd | |||
| Generation Authentication and Key Agreement (EAP-AKA')", | Generation Authentication and Key Agreement (EAP-AKA')", | |||
| RFC 5448, May 2009. | RFC 5448, May 2009. | |||
| [HKDF-paper] | [HKDF-paper] | |||
| Krawczyk, H., "On Extract-then-Expand Key Derivation | Krawczyk, H., "On Extract-then-Expand Key Derivation | |||
| Functions and an HMAC-based KDF", | Functions and an HMAC-based KDF", | |||
| URL http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf, | URL http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf, | |||
| March 2008. | March 2008. | |||
| [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | |||
| RFC 4306, December 2005. | RFC 4306, December 2005. | |||
| [PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | [PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | |||
| and A. Yegin, "Protocol for Carrying Authentication for | and A. Yegin, "Protocol for Carrying Authentication for | |||
| Network Access (PANA)", RFC 5191, December 2008. | Network Access (PANA)", RFC 5191, December 2008. | |||
| [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography | ||||
| Specification Version 2.0", RFC 2898, September 2000. | ||||
| Appendix A. Test Vectors | Appendix A. Test Vectors | |||
| This appendix provides test vectors for SHA-256 and SHA-1 hash | This appendix provides test vectors for SHA-256 and SHA-1 hash | |||
| functions [SHS]. | functions [SHS]. | |||
| A.1. Test Case 1 | A.1. Test Case 1 | |||
| Basic test case with SHA-256 | Basic test case with SHA-256 | |||
| Hash = SHA-256 | Hash = SHA-256 | |||
| IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | |||
| salt = 0x000102030405060708090a0b0c (14 octets) | salt = 0x000102030405060708090a0b0c (13 octets) | |||
| info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) | info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) | |||
| L = 42 | L = 42 | |||
| PRK = <...to be added...> (32 octets) | PRK = 0x077709362c2e32df0ddc3f0dc47bba63 | |||
| OKM = <...to be added...> (42 octets) | 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) | |||
| OKM = 0x3cb25f25faacd57a90434f64d0362f2a | ||||
| 2d2d0a90cf1a5a4c5db02d56ecc4c5bf | ||||
| 34007208d5b887185865 (42 octets) | ||||
| A.2. Test Case 2 | A.2. Test Case 2 | |||
| Test with SHA-256 and longer inputs/outputs | Test with SHA-256 and longer inputs/outputs | |||
| Hash = SHA-256 | Hash = SHA-256 | |||
| IKM = 0x000102030405060708090a0b0c0d0e0f | IKM = 0x000102030405060708090a0b0c0d0e0f | |||
| 101112131415161718191a1b1c1d1e1f | 101112131415161718191a1b1c1d1e1f | |||
| 202122232425262728292a2b2c2d2e2f | 202122232425262728292a2b2c2d2e2f | |||
| 303132333435363738393a3b3c3d3e3f | 303132333435363738393a3b3c3d3e3f | |||
| 404142434445464748494a4b4c4d4e4f (80 octets) | 404142434445464748494a4b4c4d4e4f (80 octets) | |||
| salt = 0x606162636465666768696a6b6c6d6e6f | salt = 0x606162636465666768696a6b6c6d6e6f | |||
| 707172737475767778797a7b7c7d7e7f | 707172737475767778797a7b7c7d7e7f | |||
| 808182838485868788898a8b8c8d8e8f | 808182838485868788898a8b8c8d8e8f | |||
| 909192939495969798999a9b9c9d9e9f | 909192939495969798999a9b9c9d9e9f | |||
| a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) | a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) | |||
| info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf | info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf | |||
| c0c1c2c3c4c5c6c7c8c9cacbcccdcecf | c0c1c2c3c4c5c6c7c8c9cacbcccdcecf | |||
| d0d1d2d3d4d5d6d7d8d9dadbdcdddedf | d0d1d2d3d4d5d6d7d8d9dadbdcdddedf | |||
| e0e1e2e3e4e5e6e7e8e9eaebecedeeef | e0e1e2e3e4e5e6e7e8e9eaebecedeeef | |||
| f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) | f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) | |||
| L = 82 | L = 82 | |||
| PRK = <...to be added...> (32 octets) | PRK = 0x06a6b88c5853361a06104c9ceb35b45c | |||
| OKM = <...to be added...> (82 octets) | ef760014904671014a193f40c15fc244 (32 octets) | |||
| OKM = 0xb11e398dc80327a1c8e7f78c596a4934 | ||||
| 4f012eda2d4efad8a050cc4c19afa97c | ||||
| 59045a99cac7827271cb41c65e590e09 | ||||
| da3275600c2f09b8367793a9aca3db71 | ||||
| cc30c58179ec3e87c14c01d5c1f3434f | ||||
| 1d87 (82 octets) | ||||
| A.3. Test Case 3 | A.3. Test Case 3 | |||
| Test with SHA-256 and empty salt/info | Test with SHA-256 and empty salt/info | |||
| Hash = SHA-256 | Hash = SHA-256 | |||
| IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | |||
| salt = (0 octets) | salt = (0 octets) | |||
| info = (0 octets) | info = (0 octets) | |||
| L = 42 | L = 42 | |||
| PRK = <...to be added...> (32 octets) | PRK = 0x19ef24a32c717b167f33a91d6f648bdf | |||
| OKM = <...to be added...> (42 octets) | 96596776afdb6377ac434c1c293ccb04 (32 octets) | |||
| OKM = 0x8da4e775a563c18f715f802a063c5a31 | ||||
| b8a11f5c5ee1879ec3454e5f3c738d2d | ||||
| 9d201395faa4b61a96c8 (42 octets) | ||||
| A.4. Test Case 4 | A.4. Test Case 4 | |||
| Basic test case with SHA-1 | Basic test case with SHA-1 | |||
| Hash = SHA-1 | Hash = SHA-1 | |||
| IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (12 octets) | IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets) | |||
| salt = 0x000102030405060708090a0b0c (14 octets) | salt = 0x000102030405060708090a0b0c (13 octets) | |||
| info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) | info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) | |||
| L = 42 | L = 42 | |||
| PRK = <...to be added...> (20 octets) | PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets) | |||
| OKM = <...to be added...> (42 octets) | OKM = 0x085a01ea1b10f36933068b56efa5ad81 | |||
| a4f14b822f5b091568a9cdd4f155fda2 | ||||
| c22e422478d305f3f896 (42 octets) | ||||
| A.5. Test Case 5 | A.5. Test Case 5 | |||
| Test with SHA-1 and longer inputs/outputs | Test with SHA-1 and longer inputs/outputs | |||
| Hash = SHA-1 | Hash = SHA-1 | |||
| IKM = 0x000102030405060708090a0b0c0d0e0f | IKM = 0x000102030405060708090a0b0c0d0e0f | |||
| 101112131415161718191a1b1c1d1e1f | 101112131415161718191a1b1c1d1e1f | |||
| 202122232425262728292a2b2c2d2e2f | 202122232425262728292a2b2c2d2e2f | |||
| 303132333435363738393a3b3c3d3e3f | 303132333435363738393a3b3c3d3e3f | |||
| skipping to change at page 11, line 27 ¶ | skipping to change at page 11, line 42 ¶ | |||
| 808182838485868788898a8b8c8d8e8f | 808182838485868788898a8b8c8d8e8f | |||
| 909192939495969798999a9b9c9d9e9f | 909192939495969798999a9b9c9d9e9f | |||
| a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) | a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) | |||
| info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf | info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf | |||
| c0c1c2c3c4c5c6c7c8c9cacbcccdcecf | c0c1c2c3c4c5c6c7c8c9cacbcccdcecf | |||
| d0d1d2d3d4d5d6d7d8d9dadbdcdddedf | d0d1d2d3d4d5d6d7d8d9dadbdcdddedf | |||
| e0e1e2e3e4e5e6e7e8e9eaebecedeeef | e0e1e2e3e4e5e6e7e8e9eaebecedeeef | |||
| f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) | f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) | |||
| L = 82 | L = 82 | |||
| PRK = <...to be added...> (20 octets) | PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) | |||
| OKM = <...to be added...> (82 octets) | OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb | |||
| ff6adcae899d92191fe4305673ba2ffe | ||||
| 8fa3f1a4e5ad79f3f334b3b202b2173c | ||||
| 486ea37ce3d397ed034c7f9dfeb15c5e | ||||
| 927336d0441f4c4300e2cff0d0900b52 | ||||
| d3b4 (82 octets) | ||||
| A.6. Test Case 6 | A.6. Test Case 6 | |||
| Test with SHA-1 and empty salt/info | Test with SHA-1 and empty salt/info | |||
| Hash = SHA-1 | Hash = SHA-1 | |||
| IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) | |||
| salt = (0 octets) | salt = (0 octets) | |||
| info = (0 octets) | info = (0 octets) | |||
| L = 42 | L = 42 | |||
| PRK = <...to be added...> (20 octets) | PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets) | |||
| OKM = <...to be added...> (42 octets) | OKM = 0x0ac1af7002b3d761d1e55298da9d0506 | |||
| b9ae52057220a306e07b6b87e8df21d0 | ||||
| Appendix B. Design Rationale | ea00033de03984d34918 (42 octets) | |||
| This sections briefely describes the goals of the design, and | ||||
| rationale behind it. For a more comprehensive treatment, see | ||||
| [HKDF-paper]. | ||||
| (...to be written...) | ||||
| Authors' Addresses | Authors' Addresses | |||
| Hugo Krawczyk | Hugo Krawczyk | |||
| IBM Research | IBM Research | |||
| 19 Skyline Drive | 19 Skyline Drive | |||
| Hawthorne, NY 10532 | Hawthorne, NY 10532 | |||
| USA | USA | |||
| Email: hugo@ee.technion.ac.il | Email: hugo@ee.technion.ac.il | |||
| End of changes. 26 change blocks. | ||||
| 69 lines changed or deleted | 93 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||