doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5869.txt b/doc/rfc/rfc5869.txt
new file mode 100644
index 0000000..be4eebe
--- /dev/null
+++ b/doc/rfc/rfc5869.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       H. Krawczyk
+Request for Comments: 5869                                  IBM Research
+Category: Informational                                        P. Eronen
+ISSN: 2070-1721                                                    Nokia
+                                                                May 2010
+
+
+      HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+
+Abstract
+
+   This document specifies a simple Hashed Message Authentication Code
+   (HMAC)-based key derivation function (HKDF), which can be used as a
+   building block in various protocols and applications.  The key
+   derivation function (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
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5869.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Krawczyk & Eronen             Informational                     [Page 1]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+1.  Introduction
+
+   A key derivation function (KDF) is a basic and essential component of
+   cryptographic systems.  Its goal is to take some source of initial
+   keying material and derive from it one or more cryptographically
+   strong secret keys.
+
+   This document specifies a simple HMAC-based [HMAC] KDF, named HKDF,
+   which can be used as a building block in various protocols and
+   applications, and is already used in several IETF protocols,
+   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 and does not change or update existing specifications using
+   this KDF.
+
+   HKDF follows the "extract-then-expand" paradigm, where the KDF
+   logically consists of two modules.  The first stage takes the input
+   keying material and "extracts" from it a fixed-length pseudorandom
+   key K.  The second stage "expands" the key K into several additional
+   pseudorandom keys (the output of the KDF).
+
+   In many applications, the input keying material is not necessarily
+   distributed uniformly, and the attacker may have some partial
+   knowledge about it (for example, a Diffie-Hellman value computed by a
+   key exchange protocol) or even partial control of it (as in some
+   entropy-gathering applications).  Thus, the goal of the "extract"
+   stage is to "concentrate" the possibly dispersed entropy of the input
+   keying material into a short, but cryptographically strong,
+   pseudorandom key.  In some applications, the input may already be a
+   good pseudorandom key; in these cases, the "extract" stage is not
+   necessary, and the "expand" part can be used alone.
+
+   The second stage "expands" the pseudorandom key to the desired
+   length; the number and lengths of the output keys depend on the
+   specific cryptographic algorithms for which the keys are needed.
+
+   Note that some existing KDF specifications, such as NIST Special
+   Publication 800-56A [800-56A], NIST Special Publication 800-108
+   [800-108] and IEEE Standard 1363a-2004 [1363a], either only consider
+   the second stage (expanding a pseudorandom key), or do not explicitly
+   differentiate between the "extract" and "expand" stages, often
+   resulting in design shortcomings.  The goal of this specification is
+   to accommodate a wide range of KDF requirements while minimizing the
+   assumptions about the underlying hash function.  The "extract-then-
+   expand" paradigm supports well this goal (see [HKDF-paper] for more
+   information about the design rationale).
+
+
+
+Krawczyk & Eronen             Informational                     [Page 2]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+2.  HMAC-based Key Derivation Function (HKDF)
+
+2.1.  Notation
+
+   HMAC-Hash denotes the HMAC function [HMAC] instantiated with hash
+   function 'Hash'.  HMAC always has two arguments: the first is a key
+   and the second an input (or message).  (Note that in the extract
+   step, 'IKM' is used as the HMAC input, not as the HMAC key.)
+
+   When the message is composed of several elements we use concatenation
+   (denoted |) in the second argument; for example, HMAC(K, elem1 |
+   elem2 | elem3).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+2.2.  Step 1: Extract
+
+   HKDF-Extract(salt, IKM) -> PRK
+
+   Options:
+      Hash     a hash function; HashLen denotes the length of the
+               hash function output in octets
+
+   Inputs:
+      salt     optional salt value (a non-secret random value);
+               if not provided, it is set to a string of HashLen zeros.
+      IKM      input keying material
+
+   Output:
+      PRK      a pseudorandom key (of HashLen octets)
+
+   The output PRK is calculated as follows:
+
+   PRK = HMAC-Hash(salt, IKM)
+
+2.3.  Step 2: Expand
+
+   HKDF-Expand(PRK, info, L) -> OKM
+
+   Options:
+      Hash     a hash function; HashLen denotes the length of the
+               hash function output in octets
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                     [Page 3]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+   Inputs:
+      PRK      a pseudorandom key of at least HashLen octets
+               (usually, the output from the extract step)
+      info     optional context and application specific information
+               (can be a zero-length string)
+      L        length of output keying material in octets
+               (<= 255*HashLen)
+
+   Output:
+      OKM      output keying material (of L octets)
+
+   The output OKM is calculated as follows:
+
+   N = ceil(L/HashLen)
+   T = T(1) | T(2) | T(3) | ... | T(N)
+   OKM = first L octets of T
+
+   where:
+   T(0) = empty string (zero length)
+   T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
+   T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
+   T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
+   ...
+
+   (where the constant concatenated to the end of each T(n) is a
+   single octet.)
+
+3.  Notes to HKDF Users
+
+   This section contains a set of guiding principles regarding the use
+   of HKDF.  A much more extensive account of such principles and design
+   rationale can be found in [HKDF-paper].
+
+3.1.  To Salt or not to Salt
+
+   HKDF is defined to operate with and without random salt.  This is
+   done to accommodate applications where a salt value is not available.
+   We stress, however, that the use of salt adds significantly to the
+   strength of HKDF, ensuring independence between different uses of the
+   hash function, supporting "source-independent" extraction, and
+   strengthening the analytical results that back the HKDF design.
+
+   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
+   are available to many applications.  For example, a pseudorandom
+   number generator (PRNG) that continuously produces outputs by
+   applying HKDF to renewable pools of entropy (e.g., sampled system
+   events) can fix a salt value and use it for multiple applications of
+
+
+
+Krawczyk & Eronen             Informational                     [Page 4]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+   HKDF without having to protect the secrecy of the salt.  In a
+   different application domain, a key agreement protocol deriving
+   cryptographic keys from a Diffie-Hellman exchange can derive a salt
+   value from public nonces exchanged and authenticated between
+   communicating parties as part of the key agreement (this is the
+   approach taken in [IKEv2]).
+
+   Ideally, the salt value is a random (or pseudorandom) string of the
+   length HashLen.  Yet, even a salt value of less quality (shorter in
+   size or with limited entropy) may still make a significant
+   contribution to the security of the output keying material; designers
+   of applications are therefore encouraged to provide salt values to
+   HKDF if such values can be obtained by the application.
+
+   It is worth noting that, while not the typical case, some
+   applications may even have a secret salt value available for use; in
+   such a case, HKDF provides an even stronger security guarantee.  An
+   example of such application is IKEv1 in its "public-key encryption
+   mode", where the "salt" to the extractor is computed from nonces that
+   are secret; similarly, the pre-shared mode of IKEv1 uses a secret
+   salt derived from the pre-shared key.
+
+3.2.  The 'info' Input to HKDF
+
+   While the 'info' value is optional in the definition of HKDF, it is
+   often of great importance in applications.  Its main objective is to
+   bind the derived key material to application- and context-specific
+   information.  For example, 'info' may contain a protocol number,
+   algorithm identifiers, user identities, etc.  In particular, it may
+   prevent the derivation of the same keying material for different
+   contexts (when the same input key material (IKM) is used in such
+   different contexts).  It may also accommodate additional inputs to
+   the key expansion part, if so desired (e.g., an application may want
+   to bind the key material to its length L, thus making L part of the
+   'info' field).  There is one technical requirement from 'info': it
+   should be independent of the input key material value IKM.
+
+3.3.  To Skip or not to Skip
+
+   In some applications, the input key material IKM may already be
+   present as a cryptographically strong key (for example, the premaster
+   secret in TLS RSA cipher suites would be a pseudorandom string,
+   except for the first two octets).  In this case, one can skip the
+   extract part and use IKM directly to key HMAC in the expand step.  On
+   the other hand, applications may still use the extract part for the
+   sake of compatibility with the general case.  In particular, if IKM
+   is random (or pseudorandom) but longer than an HMAC key, the extract
+   step can serve to output a suitable HMAC key (in the case of HMAC
+
+
+
+Krawczyk & Eronen             Informational                     [Page 5]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+   this shortening via the extractor is not strictly necessary since
+   HMAC is defined to work with long keys too).  Note, however, that if
+   the IKM is a Diffie-Hellman value, as in the case of TLS with Diffie-
+   Hellman, then the extract part SHOULD NOT be skipped.  Doing so would
+   result in using the Diffie-Hellman value g^{xy} itself (which is NOT
+   a uniformly random or pseudorandom string) as the key PRK for HMAC.
+   Instead, HKDF should apply the extract step to g^{xy} (preferably
+   with a salt value) and use the resultant PRK as a key to HMAC in the
+   expansion part.
+
+   In the case where the amount of required key bits, L, is no more than
+   HashLen, one could use PRK directly as the OKM.  This, however, is
+   NOT RECOMMENDED, especially because it would omit the use of 'info'
+   as part of the derivation process (and adding 'info' as an input to
+   the extract step is not advisable -- see [HKDF-paper]).
+
+3.4.  The Role of Independence
+
+   The analysis of key derivation functions assumes that the input
+   keying material (IKM) comes from some source modeled as a probability
+   distribution over bit streams of a certain length (e.g., streams
+   produced by an entropy pool, values derived from Diffie-Hellman
+   exponents chosen at random, etc.); each instance of IKM is a sample
+   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'
+   sampled from the (same) source distribution, the resultant keys OKM
+   and OKM' are essentially independent of each other (in a statistical
+   or computational sense).  To achieve this goal, it is important that
+   inputs to KDF are selected from appropriate input distributions and
+   also that inputs are chosen independently of each other (technically,
+   it is necessary that each sample will have sufficient entropy, even
+   when conditioned on other inputs to KDF).
+
+   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
+   same salt value can be used with multiple IKM values, it is assumed
+   that salt values are independent of the input keying material.  In
+   particular, an application needs to make sure that salt values are
+   not chosen or manipulated by an attacker.  As an example, consider
+   the case (as in IKE) where the salt is derived from nonces supplied
+   by the parties in a key exchange protocol.  Before the protocol can
+   use such salt to derive keys, it needs to make sure that these nonces
+   are authenticated as coming from the legitimate parties rather than
+   selected by the attacker (in IKE, for example this authentication is
+   an integral part of the authenticated Diffie-Hellman exchange).
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                     [Page 6]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+4.  Applications of HKDF
+
+   HKDF is intended for use in a wide variety of KDF applications.
+   These include the building of pseudorandom generators from imperfect
+   sources of randomness (such as a physical random number generator
+   (RNG)); the generation of pseudorandomness out of weak sources of
+   randomness, such as entropy collected from system events, user's
+   keystrokes, etc.; the derivation of cryptographic keys from a shared
+   Diffie-Hellman value in a key-agreement protocol; derivation of
+   symmetric keys from a hybrid public-key encryption scheme; key
+   derivation for key-wrapping mechanisms; and more.  All of these
+   applications can benefit from the simplicity and multi-purpose nature
+   of HKDF, as well as from its analytical foundation.
+
+   On the other hand, it is anticipated that some applications will not
+   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
+   scheme.  One significant example is the derivation of cryptographic
+   keys from a source of low entropy, such as a user's password.  The
+   extract step in HKDF can concentrate existing entropy but cannot
+   amplify entropy.  In the case of password-based KDFs, a main goal is
+   to slow down dictionary attacks using two ingredients: a salt value,
+   and the intentional slowing of the key derivation computation.  HKDF
+   naturally accommodates the use of salt; however, a slowing down
+   mechanism is not part of this specification.  Applications interested
+   in a password-based KDF should consider whether, for example, [PKCS5]
+   meets their needs better than HKDF.
+
+5.  Security Considerations
+
+   In spite of the simplicity of HKDF, there are many security
+   considerations that have been taken into account in the design and
+   analysis of this construction.  An exposition of all of these aspects
+   is beyond the scope of this document.  Please refer to [HKDF-paper]
+   for detailed information, including rationale for the design and for
+   the guidelines presented in Section 3.
+
+   A major effort has been made in the above paper [HKDF-paper] to
+   provide a cryptographic analysis of HKDF as a multi-purpose KDF that
+   exercises much care in the way it utilizes cryptographic hash
+   functions.  This is particularly important due to the limited
+   confidence we have in the strength of current hash functions.  This
+   analysis, however, does not imply the absolute security of any
+   scheme, and it depends heavily on the strength of the underlying hash
+   function and on modeling choices.  Yet, it serves as a strong
+   indication of the correct structure of the HKDF design and its
+   advantages over other common KDF schemes.
+
+
+
+
+Krawczyk & Eronen             Informational                     [Page 7]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+6.  Acknowledgments
+
+   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.
+
+7.  References
+
+7.1.  Normative References
+
+   [HMAC]       Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+                Hashing for Message Authentication", RFC 2104,
+                February 1997.
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SHS]        National Institute of Standards and Technology, "Secure
+                Hash Standard", FIPS PUB 180-3, October 2008.
+
+7.2.  Informative References
+
+   [1363a]      Institute of Electrical and Electronics Engineers, "IEEE
+                Standard Specifications for Public-Key Cryptography -
+                Amendment 1: Additional Techniques", IEEE Std
+                1363a-2004, 2004.
+
+   [800-108]    National Institute of Standards and Technology,
+                "Recommendation for Key Derivation Using Pseudorandom
+                Functions", NIST Special Publication 800-108,
+                November 2008.
+
+   [800-56A]    National Institute of Standards and Technology,
+                "Recommendation for Pair-Wise Key Establishment Schemes
+                Using Discrete Logarithm Cryptography (Revised)", NIST
+                Special Publication 800-56A, March 2007.
+
+   [EAP-AKA]    Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
+                Extensible Authentication Protocol Method for 3rd
+                Generation Authentication and Key Agreement (EAP-AKA')",
+                RFC 5448, May 2009.
+
+   [HKDF-paper] Krawczyk, H., "Cryptographic Extraction and Key
+                Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010
+                (to appear), 2010, <http://eprint.iacr.org/2010/264>.
+
+   [IKEv2]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+                Protocol", RFC 4306, December 2005.
+
+
+
+Krawczyk & Eronen             Informational                     [Page 8]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+   [PANA]       Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
+                and A. Yegin, "Protocol for Carrying Authentication for
+                Network Access (PANA)", RFC 5191, May 2008.
+
+   [PKCS5]      Kaliski, B., "PKCS #5: Password-Based Cryptography
+                Specification Version 2.0", RFC 2898, September 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                     [Page 9]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+Appendix A.  Test Vectors
+
+   This appendix provides test vectors for SHA-256 and SHA-1 hash
+   functions [SHS].
+
+A.1.  Test Case 1
+
+   Basic test case with SHA-256
+
+   Hash = SHA-256
+   IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
+   salt = 0x000102030405060708090a0b0c (13 octets)
+   info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
+   L    = 42
+
+   PRK  = 0x077709362c2e32df0ddc3f0dc47bba63
+          90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets)
+   OKM  = 0x3cb25f25faacd57a90434f64d0362f2a
+          2d2d0a90cf1a5a4c5db02d56ecc4c5bf
+          34007208d5b887185865 (42 octets)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                    [Page 10]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+A.2.  Test Case 2
+
+   Test with SHA-256 and longer inputs/outputs
+
+   Hash = SHA-256
+   IKM  = 0x000102030405060708090a0b0c0d0e0f
+          101112131415161718191a1b1c1d1e1f
+          202122232425262728292a2b2c2d2e2f
+          303132333435363738393a3b3c3d3e3f
+          404142434445464748494a4b4c4d4e4f (80 octets)
+   salt = 0x606162636465666768696a6b6c6d6e6f
+          707172737475767778797a7b7c7d7e7f
+          808182838485868788898a8b8c8d8e8f
+          909192939495969798999a9b9c9d9e9f
+          a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
+   info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
+          c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
+          d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
+          e0e1e2e3e4e5e6e7e8e9eaebecedeeef
+          f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
+   L    = 82
+
+   PRK  = 0x06a6b88c5853361a06104c9ceb35b45c
+          ef760014904671014a193f40c15fc244 (32 octets)
+   OKM  = 0xb11e398dc80327a1c8e7f78c596a4934
+          4f012eda2d4efad8a050cc4c19afa97c
+          59045a99cac7827271cb41c65e590e09
+          da3275600c2f09b8367793a9aca3db71
+          cc30c58179ec3e87c14c01d5c1f3434f
+          1d87 (82 octets)
+
+A.3.  Test Case 3
+
+   Test with SHA-256 and zero-length salt/info
+
+   Hash = SHA-256
+   IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
+   salt = (0 octets)
+   info = (0 octets)
+   L    = 42
+
+   PRK  = 0x19ef24a32c717b167f33a91d6f648bdf
+          96596776afdb6377ac434c1c293ccb04 (32 octets)
+   OKM  = 0x8da4e775a563c18f715f802a063c5a31
+          b8a11f5c5ee1879ec3454e5f3c738d2d
+          9d201395faa4b61a96c8 (42 octets)
+
+
+
+
+
+Krawczyk & Eronen             Informational                    [Page 11]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+A.4.  Test Case 4
+
+   Basic test case with SHA-1
+
+   Hash = SHA-1
+   IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets)
+   salt = 0x000102030405060708090a0b0c (13 octets)
+   info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
+   L    = 42
+
+   PRK  = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets)
+   OKM  = 0x085a01ea1b10f36933068b56efa5ad81
+          a4f14b822f5b091568a9cdd4f155fda2
+          c22e422478d305f3f896 (42 octets)
+
+A.5.  Test Case 5
+
+   Test with SHA-1 and longer inputs/outputs
+
+   Hash = SHA-1
+   IKM  = 0x000102030405060708090a0b0c0d0e0f
+          101112131415161718191a1b1c1d1e1f
+          202122232425262728292a2b2c2d2e2f
+          303132333435363738393a3b3c3d3e3f
+          404142434445464748494a4b4c4d4e4f (80 octets)
+   salt = 0x606162636465666768696a6b6c6d6e6f
+          707172737475767778797a7b7c7d7e7f
+          808182838485868788898a8b8c8d8e8f
+          909192939495969798999a9b9c9d9e9f
+          a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
+   info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
+          c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
+          d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
+          e0e1e2e3e4e5e6e7e8e9eaebecedeeef
+          f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
+   L    = 82
+
+   PRK  = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets)
+   OKM  = 0x0bd770a74d1160f7c9f12cd5912a06eb
+          ff6adcae899d92191fe4305673ba2ffe
+          8fa3f1a4e5ad79f3f334b3b202b2173c
+          486ea37ce3d397ed034c7f9dfeb15c5e
+          927336d0441f4c4300e2cff0d0900b52
+          d3b4 (82 octets)
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                    [Page 12]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+A.6.  Test Case 6
+
+   Test with SHA-1 and zero-length salt/info
+
+   Hash = SHA-1
+   IKM  = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
+   salt = (0 octets)
+   info = (0 octets)
+   L    = 42
+
+   PRK  = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets)
+   OKM  = 0x0ac1af7002b3d761d1e55298da9d0506
+          b9ae52057220a306e07b6b87e8df21d0
+          ea00033de03984d34918 (42 octets)
+
+A.7.  Test Case 7
+
+   Test with SHA-1, salt not provided (defaults to HashLen zero octets),
+   zero-length info
+
+   Hash = SHA-1
+   IKM  = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)
+   salt = not provided (defaults to HashLen zero octets)
+   info = (0 octets)
+   L    = 42
+
+   PRK  = 0x2adccada18779e7c2077ad2eb19d3f3e731385dd (20 octets)
+   OKM  = 0x2c91117204d745f3500d636a62f64f0a
+          b3bae548aa53d423b0d1f27ebba6f5e5
+          673a081d70cce7acfc48 (42 octets)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                    [Page 13]
+
+RFC 5869                 Extract-and-Expand HKDF                May 2010
+
+
+Authors' Addresses
+
+   Hugo Krawczyk
+   IBM Research
+   19 Skyline Drive
+   Hawthorne, NY 10532
+   USA
+
+   EMail: hugokraw@us.ibm.com
+
+
+   Pasi Eronen
+   Nokia Research Center
+   P.O. Box 407
+   FI-00045 Nokia Group
+   Finland
+
+   EMail: pasi.eronen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk & Eronen             Informational                    [Page 14]
+