Add ECPrivateKey for Elliptic Curve keypair generation.

crypto/ec_private_key_unittest.cc

Index: crypto/ec_private_key_unittest.cc
diff --git a/crypto/ec_private_key_unittest.cc b/crypto/ec_private_key_unittest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..4903ac2c2b39626be96c4661220b10621b1a0339
--- /dev/null
+++ b/crypto/ec_private_key_unittest.cc
@@ -0,0 +1,107 @@
+// Copyright (c) 2011 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.
+
+#include "crypto/ec_private_key.h"
+
+#include <vector>
+
+#include "base/memory/scoped_ptr.h"
+#include "testing/gtest/include/gtest/gtest.h"
+
+#if defined(USE_OPENSSL)
+// Once ECPrivateKey is implemented for OpenSSL, remove this #if block.
+TEST(ECPrivateKeyUnitTest, OpenSSLStub) {
+  scoped_ptr<crypto::ECPrivateKey> keypair1(
+      crypto::ECPrivateKey::Create());
+  ASSERT_FALSE(keypair1.get());
+}

[Ryan Sleevi, 2011/11/04 03:21:25]

nit: If/when OpenSSL is implemented, I think you should also add some gold tests
that the two can use to test interoperability between the implementations.

[mattm, 2011/11/08 02:12:27]

Good idea.

+#else
+// Generate random private keys. Export, then re-import. We should get
+// back the same exact public key, and the private key should have the same
+// value and elliptic curve params.

[Ryan Sleevi, 2011/11/04 03:21:25]

nit: Much like the existing tests for RSA, this is probably going to cause
issues for the memory tester bots. And of course, randomness can be a source of
test in-determinism.

[wtc, 2011/11/04 21:52:49]

RSA key pair generation is much slower than EC key pair
generation because an RSA key pair requires two random
*prime* numbers.  An EC key pair just need a random number.
So I don't think this test will time out when running
under valgrind or other memory check tools.

[mattm, 2011/11/08 02:12:27]

Yeah, from the linux_valgrind try run:
ECPrivateKeyUnitTest.InitRandomTest (1201 ms)
RSAPrivateKeyUnitTest.InitRandomTest (36355 ms)

+TEST(ECPrivateKeyUnitTest, InitRandomTest) {
+  const std::string password1 = "";
+  const std::string password2 = "test";
+
+  scoped_ptr<crypto::ECPrivateKey> keypair1(
+      crypto::ECPrivateKey::Create());
+  scoped_ptr<crypto::ECPrivateKey> keypair2(
+      crypto::ECPrivateKey::Create());
+  ASSERT_TRUE(keypair1.get());
+  ASSERT_TRUE(keypair2.get());
+
+  std::vector<uint8> key1value;
+  std::vector<uint8> key2value;
+  std::vector<uint8> key1params;
+  std::vector<uint8> key2params;
+  EXPECT_TRUE(keypair1->ExportValue(&key1value));
+  EXPECT_TRUE(keypair2->ExportValue(&key2value));
+  EXPECT_TRUE(keypair1->ExportECParams(&key1params));
+  EXPECT_TRUE(keypair2->ExportECParams(&key2params));
+
+  std::vector<uint8> privkey1;
+  std::vector<uint8> privkey2;
+  std::vector<uint8> pubkey1;
+  std::vector<uint8> pubkey2;

[Ryan Sleevi, 2011/11/04 03:21:25]

nit: The naming here (key as suffix) seems to conflict with the naming of the
variables at 34-37/66-70

[mattm, 2011/11/08 02:12:27]

I thought about that, but the alternatives I thought of seem overly verbose or
don't read very naturally.

+  std::vector<uint8> tmp_pubkey;
+  ASSERT_TRUE(keypair1->ExportEncryptedPrivateKey(
+      password1, &privkey1, &pubkey1));
+  ASSERT_TRUE(keypair2->ExportEncryptedPrivateKey(
+      password2, &privkey2, &pubkey2));
+  EXPECT_TRUE(keypair1->ExportPublicKey(&tmp_pubkey));
+  EXPECT_EQ(pubkey1, tmp_pubkey);
+  EXPECT_TRUE(keypair2->ExportPublicKey(&tmp_pubkey));
+  EXPECT_EQ(pubkey2, tmp_pubkey);
+
+  scoped_ptr<crypto::ECPrivateKey> keypair3(
+      crypto::ECPrivateKey::CreateFromEncryptedPrivateKeyInfo(
+          password1, privkey1, pubkey1));
+  scoped_ptr<crypto::ECPrivateKey> keypair4(
+      crypto::ECPrivateKey::CreateFromEncryptedPrivateKeyInfo(
+          password2, privkey2, pubkey2));
+  ASSERT_TRUE(keypair3.get());
+  ASSERT_TRUE(keypair4.get());
+
+  std::vector<uint8> key3value;
+  std::vector<uint8> key4value;
+  std::vector<uint8> key3params;
+  std::vector<uint8> key4params;
+  EXPECT_TRUE(keypair3->ExportValue(&key3value));
+  EXPECT_TRUE(keypair4->ExportValue(&key4value));
+  EXPECT_TRUE(keypair3->ExportECParams(&key3params));
+  EXPECT_TRUE(keypair4->ExportECParams(&key4params));
+
+  EXPECT_EQ(key1value, key3value);
+  EXPECT_EQ(key2value, key4value);
+  EXPECT_EQ(key1params, key3params);
+  EXPECT_EQ(key2params, key4params);
+
+  std::vector<uint8> pubkey3;
+  std::vector<uint8> pubkey4;
+  EXPECT_TRUE(keypair3->ExportPublicKey(&pubkey3));
+  EXPECT_TRUE(keypair4->ExportPublicKey(&pubkey4));
+
+  EXPECT_EQ(pubkey1, pubkey3);
+  EXPECT_EQ(pubkey2, pubkey4);
+}
+
+TEST(ECPrivateKeyUnitTest, BadPasswordTest) {

[Ryan Sleevi, 2011/11/04 03:21:25]

Explanation as to what the test covers?

More importantly, why test a bad password, if your iteration count for
encrypting is only 1? Is this meant to convey some security property?

[mattm, 2011/11/08 02:12:27]

No, just a functional test, wrong password should return NULL and not blow up or
leak memory or something.

+  const std::string password1 = "";
+  const std::string password2 = "test";
+
+  scoped_ptr<crypto::ECPrivateKey> keypair1(
+      crypto::ECPrivateKey::Create());
+  ASSERT_TRUE(keypair1.get());
+
+  std::vector<uint8> privkey1;
+  std::vector<uint8> pubkey1;
+  ASSERT_TRUE(keypair1->ExportEncryptedPrivateKey(
+      password1, &privkey1, &pubkey1));
+
+  scoped_ptr<crypto::ECPrivateKey> keypair2(
+      crypto::ECPrivateKey::CreateFromEncryptedPrivateKeyInfo(
+          password2, privkey1, pubkey1));
+  ASSERT_FALSE(keypair2.get());
+}
+#endif  // !defined(USE_OPENSSL)