ESAPI for Java - 2.1.0 Release Notes

1) Fixed security issue #306, a vulnerability discovered by Phillipe Arteau.
   This fix necessitated removing the deprecated encrypt() and decrupt() methods
   that were intended to provide backward compatibility with ESAPI 1.4.
   As it turns out, there was no way to fix this bug without a major rewrite
   unless these methods were removed. However, as these two methods have been
   deprecated more than 2 years ago and they are known to be insecure
   (they are vulnerable to padding oracle attacks), the ESAPI team has
   decided to remove them in accordance to their support policy.

   See comments for issue #306 for further details, as well as additional
   safety precautions that you may wish to take in the unlikely, but possible
   event that this vulnerability resulted in an actual security breach.

   Finally, since the removal of these methods constitute an interface change
   (to the Encryptor interface), this is considered a minor release (2.1)
   rather than simply a patch release (2.0.2).

   Please note that there are further updates planned to further strengthen
   the MAC that ESAPI crypt uses. However, because they will require some
   design changes, they may not be out for another month. Note that these
   fixes do not correct any *known* vulnerabilities, but will address
   some potential weaknesses in what is not included in the MAC (such as
   the crypto version).

2) Other Google Issues fixed: 257, 271, and 292 are all fixed in this release.

3) Fixed Javadoc for Encoder.encryptForJavaScript(). [Revision r1879]

4) DefaultEncryptedProperties - made minor Javadoc changes.

5) The ESAPI 2.0 Encryptor.encrypt() methods now all throw an appropriate
   IllegalArgumentException if any of the arguments are null. Previously,
   if any of the arguments were null you would either get an AssertionError
   (if you had assertions enabled) or a default NullPointerException when
   assertions were disabled.  While IllegalArgumentException is still an
   unchecked RuntimeException, note that if you were previously catching
   NullPointerExceptions for these cases, you may need to change your code.

6) The public constructor, CiphertextSerializer(CipherText ct), was changed
   to explicitly check that the parameter is not null. Previously it had
   checked with assertions which might later result in a NullPointerException
   being thrown if assertions were disabled. Now if the parameter is null,
   an appropriate IllegalArgumentException is thrown. This should not really
   affect existing code (unless you are experimenting implementing your own
   crypto) since user code should not really be using CiperTextSerializer
   directly.

7) Some of the setter methods in KeyDerivationFunction were changed to explicitly
   check for invalid arguments and throw an IllegalArgumentException rather than
   checking these parameters via assertions. This should not affect general
   user code as most would not be calling the KeyDerivationFunction class
   directly.

8) Other miscellaneous minor code clean-up, mostly to remove compiler warnings.

NOTE: A follow-up patch release is scheduled within the next few months to
      address some questionable design decisions regarding what data in
      the serialized ciphertext should be authenticated via the MAC. For
      instance, presently only the IV+ciphertext is MAC'd (as would be the
      equivalent case of when you would use an authenticated combined cipher
      mode such as GCM or CCM). A deeper analysis of the design is required
      based on findings in Google Issue # 306. I will periodically try
      to keep the ESAPI mailing lists updated with the progress so watch
      there for emerging details and anticipated schedule.

-Kevin W. Wall <kevin.w.wall@gmail.com>, 2013-08-30
