// Copyright 2011 The Chromium Authors // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. #ifdef UNSAFE_BUFFERS_BUILD // TODO(crbug.com/351564777): Remove this and convert code to safer constructs. #pragma allow_unsafe_buffers #endif #include "crypto/rsa_private_key.h" #include <stdint.h> #include <memory> #include "testing/gtest/include/gtest/gtest.h" namespace { const uint8_t kTestPrivateKeyInfo[] = …; } // namespace // Generate random private keys with two different sizes. Reimport, then // export them again. We should get back the same exact bytes. TEST(RSAPrivateKeyUnitTest, InitRandomTest) { … } // Test Copy() method. TEST(RSAPrivateKeyUnitTest, CopyTest) { … } // Test that CreateFromPrivateKeyInfo fails if there is extra data after the RSA // key. TEST(RSAPrivateKeyUnitTest, ExtraData) { … } TEST(RSAPrivateKeyUnitTest, NotRsaKey) { … } // Verify that generated public keys look good. This test data was generated // with the openssl command line tool. TEST(RSAPrivateKeyUnitTest, PublicKeyTest) { … } // These two test keys each contain an integer that has 0x00 for its most // significant byte. When encoded as ASN.1, this byte is dropped and there are // two interesting sub-cases. When the sign bit of the integer is set, an extra // null byte is added back to force the encoded value to be positive. When the // sign bit is not set, the encoded integer is just left shorter than usual. // See also: http://code.google.com/p/chromium/issues/detail?id=14877. // // Before we were handling this correctly, we would see one of two failures: // * RSAPrivateKey::CreateFromPrivateKeyInfo would return null because the // underlying windows API failed to import the key. // * The import would succeed, but incorrectly interpret the data. On export, // the key would contain different values. // // This test case verifies these two failures modes don't occur. TEST(RSAPrivateKeyUnitTest, ShortIntegers) { … } TEST(RSAPrivateKeyUnitTest, CreateFromKeyTest) { … }