Google -> GitHub Sync, 1 Feb 2017 (#19)

* Removing duplicates from BigIntegerTest.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142548323

* Remove @NoPresubmitCheck from testModifiedPublic() and testModifiedPublicSpec(). The corresponding bug was fixed in BC 1.55 or BC 1.56.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142561682

* minor typos

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142743772

* Regenerating the test vectors for ECDSA:
- this adds more comments for bugtypes and modifications or the signatures.
- fixes some ugly formatting.
- adds some additional test vectors.

There are no new bugs.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144619819

* Regenerating DSA test vectors:
This adds a few more test vectors.
The test vectors are now divided between test vectors with valid BER encodings
and test vectors with invalid DER encodings.
The description of the test vector better describes what was modified.

Also fixing issue #17 on Github: testVectors in DsaTest not using the message parameter

There are no changes to the presubmit tests. Tests that can be enabled because of the
Oracles security update will be added in another CL.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144814889

* Regenerating test vectors for EcdhTest.java

Merging a test with small order into the test vectors.
Fixing ASN encoding of 0 (from 0200 to 020100, i.e. length must be > 0).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144815129

* Regenerating RSA signatures.

Adding test vectors that were removed because of b/31575502. Oracle fixes this with CVE-2016-5547.

Changing ASN tags with value 0x50 to 0x30 (0x50 would be something like sequence of sequence but does not exist), hence the old vectors are unlikely to cause problems.

Adding more modifications of OIDs. The new vectors unpack the OIDs and change the nodes.
(E.g. the OID for sha256 is the hexadecimal string "608648016503040201" which is an
ASN encoding of "2.16.840.1.101.3.4.2.1". The new test vectors include invalid encoding,
encodings with additional nodes, deleted nodes and nodes that are changed to large integers)

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144846826

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145060646

* Removing presubmit restrictions for tests that have been fixed internally and upstream.
Mainly these are tests with CVEs that were announced during the Jan 17 security update
by Oracle.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145397539

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145418516

* Adding the CVE numbers from Oracles Jan 17 security update to the documentation.
Minor changes to some test vectors: Some of the garbage added to the ASN encoding
was itself incorrect and has been replaced.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145650774

* ECDSA MODIFIED_SIGNATURES should be public now.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146186539

doc/index.md

@@ -1,7 +1,7 @@
 # Project Wycheproof
 
 This page describes the goals and strategies of project Wycheproof. See
-[README](../README.md) for introduction to the project.
+[README](../README.md) for an introduction to the project.
 
 ## Defense in depth
 
@@ -33,7 +33,7 @@ rather than exploitability. Examples:
 
 One of the goals of Wycheproof is to test for compatibility issues.
 Switching JCE providers should not introduce vulnerabilities simply because
-the solution was developed with another provider.
+the solution was developed by another provider.
 
 An example for this was the following observation: When using AES-GCM then
 javax.crypto.CipherInputStream worked sort of with JCE and
@@ -49,10 +49,10 @@ cryptographic libraries based on the bugs found would be biased:
 * Libraries used internally in Google get more attention.
   Serious vulnerabilities in these libraries should be fixed at the time the
   tests are added to Wycheproof.  On the other hand it is also likely that
-  tests find a larger number of bugs in thsese libraries when old versions are
+  tests find a larger number of bugs in these libraries when old versions are
   tested.
 * Tests often check for expected behaviour and compatibility.
-  Excpected behaviour is often defined by a prominent library.
+  Expected behaviour is often defined by a prominent library.
   Pointing out such problems can therefore penalize smaller third party
   libraries.
 * We are working toward covering as many potential vulnerabilities as possible
@@ -71,7 +71,7 @@ We should promote robust interfaces with the goal to simplify
 the use of the library, codereviews of applications using the
 library and testing the library.
 
-* When cryptrographic primitives require randomness then the random
+* When cryptographic primitives require randomness then the random
   numbers should be chosen by the library. It shouldn't be possible
   for a user to provide randomness. If the library itself chooses the
   randomness then it is possible (at least to some degree) to check

java/com/google/security/wycheproof/testcases/AesGcmTest.java

@@ -16,13 +16,18 @@
 
 package com.google.security.wycheproof;
 
+import com.google.security.wycheproof.WycheproofRunner.ExcludedTest;
+import com.google.security.wycheproof.WycheproofRunner.ProviderType;
+import com.google.security.wycheproof.WycheproofRunner.SlowTest;
 import java.nio.ByteBuffer;
 import java.security.AlgorithmParameterGenerator;
 import java.security.AlgorithmParameters;
 import java.security.InvalidAlgorithmParameterException;
 import java.security.InvalidKeyException;
 import java.security.NoSuchAlgorithmException;
+import java.security.SecureRandom;
 import java.util.ArrayList;
+import java.util.Arrays;
 import javax.crypto.Cipher;
 import javax.crypto.ShortBufferException;
 import javax.crypto.spec.GCMParameterSpec;
@@ -178,6 +183,41 @@ public void testLateUpdateAAD() throws Exception {
     }
   }
 
+  /**
+   * JCE has a dangerous feature: after a doFinal the cipher is typically reinitialized using the
+   * previous IV. This "feature" can easily break AES-GCM usages, because encrypting twice with
+   * the same key and IV leaks the authentication key. Hence any reasonable implementation of
+   * AES-GCM should not allow this. The expected behaviour of OpenJDK can be derived from the tests
+   * in jdk/test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java.
+   * OpenJDK does not allow two consecutive initializations for encryption with the same key and IV.
+   *
+   * <p>The test here is weaker than the restrictions in OpenJDK. The only requirement here is that
+   * reusing a Cipher without an explicit init() is caught.
+   *
+   * <p>BouncyCastle 1.52 failed this test
+   *
+   * <p>Conscrypt failed this test
+   */
+  public void testIvReuse() throws Exception {
+    for (GcmTestVector test : getTestVectors()) {
+      Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
+      cipher.init(Cipher.ENCRYPT_MODE, test.key, test.parameters);
+      cipher.updateAAD(test.aad);
+      byte[] ct1 = cipher.doFinal(test.pt);
+      try {
+        byte[] ct2 = cipher.doFinal(test.pt);
+        fail(
+            "It should not possible to reuse an IV."
+                + " ct1:"
+                + TestUtil.bytesToHex(ct1)
+                + " ct2:"
+                + TestUtil.bytesToHex(ct2));
+      } catch (java.lang.IllegalStateException ex) {
+        // This is expected.
+      }
+    }
+  }
+
   /** Encryption with ByteBuffers. */
   public void testByteBuffer() throws Exception {
     for (GcmTestVector test : getTestVectors()) {
@@ -370,4 +410,62 @@ public void testDefaultTagSizeAlgorithmParameterGenerator() throws Exception {
     byte[] output = cipher.doFinal(input);
     assertEquals(input.length + 16, output.length);
   }
+
+  /**
+   * Test AES-GCM wrapped around counter bug which leaks plaintext and authentication key. Let's
+   * consider 12-byte IV, counter = IV || 0^31 || 1. For each encryption block, the last 4 bytes of
+   * the counter is increased by 1. After 2^32 blocks, the counter will be wrapped around causing
+   * counter collision and hence, leaking plaintext and authentication key as explained below. The
+   * library must make a check to make sure that the plaintext's length never exceeds 2^32 - 2
+   * blocks. Note that this is different from usual IV collisions because it happens even if users
+   * use different IVs. <br>
+   * We have: <br>
+   * J0 = IV || 0^31 || 1 <br>
+   * Plaintext: P[0], P[1], P[2], .... <br>
+   * Ciphertext: <br>
+   * C[0] = Enc(K, (J0 + 1) % 2^32) XOR P[0] <br>
+   * C[1] = Enc(K, (J0 + 2) % 2^32) XOR P[1] <br>
+   * C[2] = Enc(K, (J0 + 3) % 2^32) XOR P[2] <br>
+   * ... <br>
+   * C[2^32 - 1] = Enc(K, J0) XOR P[2^32 - 1] <br>
+   * C[2^32] = Enc(K, (J0 + 1)% 2^32) XOR P[2^32] <br>
+   * It means that after 2^32 blocks, the counter is wrapped around causing counter collisions. In
+   * counter mode, once the counter is collided then it's reasonable to assume that the plaintext is
+   * leaked. As the ciphertext is already known to attacker, Enc(K, J0) is leaked. <br>
+   * Now, as the authentication tag T is computed as GHASH(H, {}, C) XOR E(K, J0), the attacker can
+   * learn GHASH(H, {}, C}. It essentially means that the attacker finds a polynomial where H is the
+   * root (see Joux attack http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf).
+   * Solving polynomial equation in GF(2^128) is enough to extract the authentication key.
+   *
+   * <p>BouncyCastle used to have this bug (CVE-2015-6644).
+   *
+   * <p>OpenJDK8 used to have this bug (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/0c3ed12cdaf5)
+   *
+   * <p>The test is slow as we have to encrypt 2^32 blocks.
+   */
+  // TODO(quannguyen): Is there a faster way to test it?
+  @ExcludedTest(
+    providers = {ProviderType.CONSCRYPT},
+    comment = "Conscrypt doesn't support streaming, would crash")
+  @SlowTest(
+    providers = {ProviderType.BOUNCY_CASTLE, ProviderType.SPONGY_CASTLE, ProviderType.OPENJDK})
+  public void testWrappedAroundCounter() throws Exception {
+    try {
+      byte[] iv = new byte[12];
+      byte[] input = new byte[16];
+      byte[] key = new byte[16];
+      (new SecureRandom()).nextBytes(key);
+      Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
+      cipher.init(
+          Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"), new GCMParameterSpec(16 * 8, iv));
+      byte[] output = cipher.update(input);
+      for (long i = 0; i < 4294967296L + 2; i++) {
+        byte[] output1 = cipher.update(input);
+        assertFalse("GCM Wrapped Around Counter" + i, Arrays.equals(output, output1));
+      }
+      fail("Expected Exception");
+    } catch (Exception expected) {
+      System.out.println("testWrappedAroundcounter:" + expected.toString());
+    }
+  }
 }

java/com/google/security/wycheproof/testcases/BigIntegerTest.java

@@ -50,17 +50,12 @@ public class BigIntegerTest extends TestCase {
         new BigInteger("164280218643672633986221"),
         new BigInteger("318665857834031151167461"),
         new BigInteger("7395010240794120709381"),
-        new BigInteger("164280218643672633986221"),
-        new BigInteger("318665857834031151167461"),
         new BigInteger("2995741773170734841812261"),
         new BigInteger("667636712015520329618581"),
         new BigInteger("3317044064679887385961981"),
         new BigInteger("3110269097300703345712981"),
         new BigInteger("552727880697763694556181"),
-        new BigInteger("360681321802296925566181"),
-        new BigInteger("7395010240794120709381"),
         new BigInteger("3404730287403079539471001"),
-        new BigInteger("164280218643672633986221"),
         // Richarg G.E. Pinch, "Some primality testing algorithms"
         // Some composites that passed Maple V's primality test.
         new BigInteger("10710604680091"),

java/com/google/security/wycheproof/testcases/DhTest.java

@@ -358,6 +358,8 @@ public void testDHDistinctParameters() throws Exception {
    * itself cannot prevent all small-subgroup attacks because of the missing parameter q in the
    * Diffie-Hellman parameters. Implementations must add additional countermeasures such as the ones
    * proposed in RFC 2785.
+   *
+   * <p> CVE-2016-1000346: BouncyCastle before v.1.56 did not validate the other parties public key.
    */
   public void testSubgroupConfinement() throws Exception {
     KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DH");

java/com/google/security/wycheproof/testcases/DhiesTest.java

@@ -35,15 +35,18 @@
  *
  * @author bleichen@google.com (Daniel Bleichenbacher)
  */
-// Tested providers:
-// BC (not recommended)
-//
 // TODO(bleichen):
 // - maybe again CipherInputStream, CipherOutputStream,
 // - byteBuffer.
 // - Exception handling
 // - Is DHIES using the key derivation function for the key stream?
 // - BouncyCastle knows an algorithm IES. Is this the same as DHIES?
+// - Bouncy fixed a padding oracle bug in version 1.56 (CVE-2016-1000345)
+//   So far we have no test for this bug mainly because this cannot be tested
+//   through the JCA interface. BC does not register and algorithm such as
+//   Cipher.DHIESWITHAES-CBC.
+// - So far only BouncyCastles is tesed because this is the only provider
+//   we use that implements DHIES.
 public class DhiesTest extends TestCase {
 
   // TODO(bleichen): This is the same as DhTest.java