Porting of HKDF changes from server.

crypto/hkdf.h

+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef GFE_QUIC_CRYPTO_BASE_HKDF_H_

[agl, 2013/02/21 15:00:43]

I'm not sure whether we are changing the include guards in the Chromium code.
rch would know.

[ramant (doing other things), 2013/02/21 22:46:59]

QUIC has included guards. Thanks for the catch.

Done.

+#define GFE_QUIC_CRYPTO_BASE_HKDF_H_

[Ryan Sleevi, 2013/02/21 17:48:31]

Yes, this header should be fixed

[ramant (doing other things), 2013/02/21 22:46:59]

Done.

+
+#include <vector>
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+#include "base/string_piece.h"
+#include "build/build_config.h"
+#include "crypto/crypto_export.h"
+
+namespace crypto {
+
+// HKDF implements the key derivation function specified in RFC 5869 (using
+// SHA-256) and outputs key material, as needed by QUIC.

[Ryan Sleevi, 2013/02/21 17:48:31]

This seems fairly specific to QUIC, in the client/server write_key and IVs.

Normally, a class in crypto:: would provide the basic interface that would
expose |output_|, and then code in the higher layer would handle splitting out
these keys.

However, consider the comments below regarding the use of |info| below.

[ramant (doing other things), 2013/02/21 22:46:59]

Will like to leave this to agl@ (because it is API change).

+class CRYPTO_EXPORT HKDF {
+ public:
+  // secret: the input secret.
+  // salt: the public salt.
+  // info: an (optional) label to distinguish different uses of HKDF.
+  // key_bytes_to_generate: the number of bytes of key material to generate.
+  // iv_bytes_to_generate: the number of bytes of IV to generate.

[Ryan Sleevi, 2013/02/21 17:48:31]

Can you please provide comments on these that explain the security parameters?

eg: does |secret| need to be some minimum length? How should |salt| be generated
- random data or from some protocol?  Why do you distinguish between |key_bytes|
and |iv_bytes|, rather than a unified form?

Doesn't RFC 5869 suggest using different |info|s for different usages (IV and
key)?

[ramant (doing other things), 2013/02/21 22:46:59]

agl@: added some comments from RFC 5869. What do you think?

[wtc, 2013/02/25 22:18:00]

I copied the current usage from TLS, which considers the
generation of client and server keys and IVs as a single
usage (called "key expansion"). This seems to be allowed
by the RFC. For example, the RFC says, on page 2:

  ... The second stage "expands" the key K into several
  additional pseudorandom keys (the output of the KDF).

without saying the second stage should be invoked once for
each output key.

+  HKDF(const base::StringPiece& secret,
+       const base::StringPiece& salt,
+       const base::StringPiece& info,
+       size_t key_bytes_to_generate,
+       size_t iv_bytes_to_generate);
+  virtual ~HKDF();
+
+  base::StringPiece client_write_key() const {
+    return client_write_key_;
+  }
+  base::StringPiece client_write_iv() const {
+    return client_write_iv_;
+  }
+  base::StringPiece server_write_key() const {
+    return server_write_key_;
+  }
+  base::StringPiece server_write_iv() const {
+    return server_write_iv_;
+  }
+
+ private:
+  std::vector<uint8> output_;
+
+  base::StringPiece client_write_key_;
+  base::StringPiece server_write_key_;
+  base::StringPiece client_write_iv_;
+  base::StringPiece server_write_iv_;
+};
+
+}  // namespace crypto
+
+#endif  // GFE_QUIC_CRYPTO_BASE_HKDF_H_