Typo and style fixes (#25)

5 files changed, 70 insertions, 66 deletions

diff --git a/README.md b/README.md
index f5cf957..07b10fd 100644
--- a/README.md
+++ b/README.md
@@ -80,13 +80,15 @@ providers in [OpenJDK](http://openjdk.java.net/).
 
 ### Usage
 
-- Install [Bazel](https://bazel.build/).
+-   Install [Bazel](https://bazel.build/).
 
-- Install
-[Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files](http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters): this enables tests with large key
-sizes. Otherwise you'll see a lot of "illegal key size" exceptions.
+-   Install [Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction
+    Policy
+    Files](http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters):
+    this enables tests with large key sizes. Otherwise you'll see a lot of
+    "illegal key size" exceptions.
 
-- Check out the tests
+-   Check out the tests
 
 ```
 git clone https://github.com/google/wycheproof.git
@@ -110,9 +112,10 @@ bazel test BouncyCastleAllTests_1_52
 bazel test BouncyCastleAllTests_*
 ```
 
-- To test a local jar, set the `WYCHEPROOF_BOUNCYCASTLE_JAR` environment variable:
+-   To test a local jar, set the `WYCHEPROOF_BOUNCYCASTLE_JAR` environment
+    variable:
 
-``` shell
+```shell
 $ WYCHEPROOF_BOUNCYCASTLE_JAR=/path/to/bouncycastle
 $ bazel test BouncyCastleTestLocal
 $ bazel test BouncyCastleAllTestsLocal
@@ -122,7 +125,7 @@ Note: bazel does not currently invalidate the build on environment changes. If
 you change the `WYCHEPROOF_BOUNCYCASTLE_JAR` environment variable, run `bazel
 clean` to force a rebuild:
 
-``` shell
+```shell
 $ WYCHEPROOF_BOUNCYCASTLE_JAR=/path/to/bouncycastle
 $ bazel test BouncyCastleTestLocal
 $ WYCHEPROOF_BOUNCYCASTLE_JAR=/path/to/other/jar
@@ -193,4 +196,3 @@ If you'd like to talk to our developers or get notified about major new
 tests, you may want to subscribe to our
 [mailing list](https://groups.google.com/forum/#!forum/wycheproof-users). To
 join, simply send an empty mail to wycheproof-users+subscribe@googlegroups.com.
-
diff --git a/doc/rsa.md b/doc/rsa.md
index 709efd1..b1f47c5 100644
--- a/doc/rsa.md
+++ b/doc/rsa.md
@@ -22,8 +22,9 @@ choice should be made by explicitly providing the desired key length during the
 initalization of a key pair generator.
 
 According to https://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html
-every implementation of the Java platform is required to implement RSA with both 1024 and
-2048 bit key sizes. Hence a 2048 bit default should not lead to compatibility problems.
+every implementation of the Java platform is required to implement RSA with both
+1024 and 2048 bit key sizes. Hence a 2048 bit default should not lead to
+compatibility problems.
 
 **Cryptographically strong random numbers:**
 So far the tests check that java.util.Random is not used. This needs to be
@@ -53,78 +54,78 @@ padding.
 
 <!-- the SUN provider used to include that block type -->
 
-**Tests**
-To test whether an implementation leaks more information than necessary a test decrypts
-some random ciphertexts and catches the exceptions. If the exceptions are distinguishable
-then the test assumes that unnecessary information about the padding is leaked.
+**Tests** To test whether an implementation leaks more information than
+necessary a test decrypts some random ciphertexts and catches the exceptions. If
+the exceptions are distinguishable then the test assumes that unnecessary
+information about the padding is leaked.
 
-Due to the nature of unit tests not every attack can be detected this way.
-Some attacks require a large number of ciphertexts to be detected if random ciphertexts
-are used. For example Klima et al. [KPR03] describe an implementation flaw that could not
-be detected with our test.
+Due to the nature of unit tests not every attack can be detected this way. Some
+attacks require a large number of ciphertexts to be detected if random
+ciphertexts are used. For example Klima et al. [KPR03] describe an
+implementation flaw that could not be detected with our test.
 
-Timing leakages because of differences in parsing the padding can leak information 
-(e.g. CVE-2015-7827). Such differences are too small to be reliably detectable in 
-unit tests.
+Timing leakages because of differences in parsing the padding can leak
+information (e.g. CVE-2015-7827). Such differences are too small to be reliably
+detectable in unit tests.
 
 ## RSA OAEP
-Manger describes an chosen ciphertext attack against RSA in [M01].
-There are implementations that were susceptible to Mangers attack, 
-e.g. [CVE-2012-5081].
+
+Manger describes an chosen ciphertext attack against RSA in [M01]. There are
+implementations that were susceptible to Mangers attack, e.g. [CVE-2012-5081].
 
 ## RSA PKCS1 signatures
 **Potential problems:**
 
-  * Some libraries parse PKCS#1 padding during signature verification incorrectly.
-  * Some libraries determine the hash function from the signature
-    (rather than encoding this in the key)
-    Effect:
-  * If the verification is buggy then an attacker might be able to generate
+*   Some libraries parse PKCS#1 padding during signature verification
+    incorrectly.
+*   Some libraries determine the hash function from the signature (rather than
+    encoding this in the key) Effect:
+*   If the verification is buggy then an attacker might be able to generate
     signatures for keys with a small (i.e. e=3) public exponent.
-  * If the hash algorithm is not determined by in an authentic manner then preimage
-    attacks against weak hashes are possible, even if the hashes are not used
-    by the signer.
-
-**Countermeasures:**
-A good way to implement RSA signature verification is described in the standard PKCS#1
-v.2.2 Section 8.2.2.
-This standard proposes to reconstruct the padding during verification and
-compare the padded hash to the value \\(s^e \bmod n\\) obtained from applying a public
-key exponentiation to the signature s.
-Since this is a recurring bug it makes also a lot of sense to avoid small
-public exponents and prefer for example e=65537 .
+*   If the hash algorithm is not determined by in an authentic manner then
+    preimage attacks against weak hashes are possible, even if the hashes are
+    not used by the signer.
+
+**Countermeasures:** A good way to implement RSA signature verification is
+described in the standard PKCS#1 v.2.2 Section 8.2.2. This standard proposes to
+reconstruct the padding during verification and compare the padded hash to the
+value $$s^e \bmod n$$ obtained from applying a public key exponentiation to the
+signature s. Since this is a recurring bug it makes also a lot of sense to avoid
+small public exponents and prefer for example e=65537 .
 
 **List of broken implementations**
 This is a large list.
 
 ## References
-[B98]: D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on the RSA encryption
-       standard PKCS# 1" Crypto 98
 
-[M01]: J. Manger, "A chosen ciphertext attack on RSA optimal asymmetric encryption padding (OAEP)
-       as standardized in PKCS# 1 v2.0", Crypto 2001 This paper shows that OAEP is susceptible
-       to a chosen ciphertext attack if error messages distinguish between different failure
-       condidtions.
-[S10]: N. Smart, "Errors matter: Breaking RSA-based PIN encryption with thirty ciphertext validity
-       queries" RSA conference, 2010 This paper shows that padding oracle attacks can be
-       successful with even a small number of queries.
+\[B98]: D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on
+the RSA encryption standard PKCS# 1" Crypto 98
+
+\[M01]: J. Manger, "A chosen ciphertext attack on RSA optimal asymmetric
+encryption padding (OAEP) as standardized in PKCS# 1 v2.0", Crypto 2001 This
+paper shows that OAEP is susceptible to a chosen ciphertext attack if error
+messages distinguish between different failure condidtions. [S10]: N. Smart,
+"Errors matter: Breaking RSA-based PIN encryption with thirty ciphertext
+validity queries" RSA conference, 2010 This paper shows that padding oracle
+attacks can be successful with even a small number of queries.
 
-[KPR03]: V. Klima, O. Pokorny, and T. Rosa, "Attacking RSA-based Sessions in SSL/TLS"
-         https://eprint.iacr.org/2003/052/
+\[KPR03]: V. Klima, O. Pokorny, and T. Rosa, "Attacking RSA-based Sessions in
+SSL/TLS" https://eprint.iacr.org/2003/052/
 
-[BFKLSST12]: "Efficient padding oracle attacks on cryptographic hardware"
-R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, Crypto 2012
+\[BFKLSST12]: "Efficient padding oracle attacks on cryptographic hardware" R.
+Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, Crypto 2012
 
-[NIST SP 800-57]: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
+\[NIST SP 800-57]:
+http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
 
-[Enisa]: "Algorithms, key size and parameters report – 2014"
+\[Enisa]: "Algorithms, key size and parameters report – 2014"
 https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014
 
 \[ECRYPT II]: Yearly Report on Algorithms and Keysizes (2011-2012),
 http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
 
-[CVE-1999-1444]: Alibaba 2.0 generated RSA key pairs with an exponent 1
+\[CVE-1999-1444]: Alibaba 2.0 generated RSA key pairs with an exponent 1
 
-[CVE-2012-5081]: Java JSSE provider leaked information through
-  exceptions and timing. Both the PKCS #1 padding and the OAEP padding were broken:
-  http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf
+\[CVE-2012-5081]: Java JSSE provider leaked information through exceptions and
+timing. Both the PKCS #1 padding and the OAEP padding were broken:
+http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf
diff --git a/java/com/google/security/wycheproof/testcases/DhiesTest.java b/java/com/google/security/wycheproof/testcases/DhiesTest.java
index 3e5bbe3..2a4815c 100644
--- a/java/com/google/security/wycheproof/testcases/DhiesTest.java
+++ b/java/com/google/security/wycheproof/testcases/DhiesTest.java
@@ -71,9 +71,9 @@ public class DhiesTest extends TestCase {
   }
 
   /**
-   * WARNING: This test uses weak crypto (i.e. DHIESWithAES), if supported. Checks that key agreement
-   * using DHIES works in the sense that it can decrypt what it encrypts. Unfortunately it seems that
-   * there is no secure mode using AES.
+   * WARNING: This test uses weak crypto (i.e. DHIESWithAES), if supported. Checks that key
+   * agreement using DHIES works in the sense that it can decrypt what it encrypts. Unfortunately it
+   * seems that there is no secure mode using AES.
    */
   @SuppressWarnings("InsecureCryptoUsage")
   public void testDhiesBasic() throws Exception {
diff --git a/java/com/google/security/wycheproof/testcases/DsaTest.java b/java/com/google/security/wycheproof/testcases/DsaTest.java
index 0e94797..edfaa74 100644
--- a/java/com/google/security/wycheproof/testcases/DsaTest.java
+++ b/java/com/google/security/wycheproof/testcases/DsaTest.java
@@ -671,7 +671,7 @@ public class DsaTest extends TestCase {
         + "22e342be484c05763939601cd667",
     "300a090380fe01090380fe01",
   };
-  
+
   @SuppressWarnings("InsecureCryptoUsage")
   public void testVectors(
       String[] signatures,
diff --git a/java/com/google/security/wycheproof/testcases/EciesTest.java b/java/com/google/security/wycheproof/testcases/EciesTest.java
index e8b1fe1..bd29bf8 100644
--- a/java/com/google/security/wycheproof/testcases/EciesTest.java
+++ b/java/com/google/security/wycheproof/testcases/EciesTest.java
@@ -217,6 +217,7 @@ public class EciesTest extends TestCase {
       fail("This should not work");
     } catch (GeneralSecurityException ex) {
       // This is as expected
+      // Bouncy Castle 1.56 throws this exception
     } catch (Exception ex) {
       fail("Expected subclass of java.security.GeneralSecurityException, but got: "
         + ex.getClass().getName());
@@ -284,7 +285,7 @@ public class EciesTest extends TestCase {
     byte[] message = "Hello".getBytes("UTF-8");
     eciesA.init(Cipher.ENCRYPT_MODE, keyPair.getPublic());
     byte[] ciphertext = eciesA.doFinal(message);
-    eciesB.init(Cipher.DECRYPT_MODE, keyPair.getPrivate(), eciesA.getParameters());
+    eciesB.init(Cipher.DECRYPT_MODE, keyPair.getPrivate(), eciesB.getParameters());
     byte[] decrypted = eciesB.doFinal(ciphertext);
     assertEquals(TestUtil.bytesToHex(message), TestUtil.bytesToHex(decrypted));
   }