Revision as of 13:22, 8 April 2010

Call for Review

OWASP is looking for some professional cryptographers and security professionals with expertise in cryptography to donate a small amount of time to review the code and/or documentation handling symmetric encryption in Enterprise Security API (ESAPI) 2.0 before this software package is considered generally available.

The latest release candidate of OWASP's ESAPI for Java (ESAPI-2.0-rc6) has recently been released. This is the second complete release candidate that contains the completely revamped symmetric encryption and the first release candidate with completed user documentation describing it.

Many of these changes to ESAPI's symmetric encryption came about as a result of the suggestions of many of you and your fellow cryptographers made on the Metzdowd cryptography mailing list. (See thread "Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI" back in mid-Sept, 2009.) Specifically advice from David A. Wagner and Ian Griggs directly affected several of the detailed design decisions.

The OWASP ESAPI team has only limited experience in applied cryptography, and realizing several of the mistakes in implementing this for ESAPI 1.4, we are interested in getting feedback on the reworked symmetric encryption portion of ESAPI to ensure it is correct and secure this time. Therefore, we are seeking experienced cryptographers as well as anyone else with an interest to comment on the ESAPI implementation and documentation.

In particular, OWASP would like to get feedback on the method used to compute derived keys and to portably serialize the 'CipherText' objects as getting these correct is imperative before people start actually using ESAPI symmetric encryption to store encrypted data. If changes to this method are required later to make it secure, it will almost certainly cause backward compatibility issues with data encrypted with older versions.

Ideally, we would like a few of you with expertise in cryptography to inspect the Java code for correctness and secure implementation. (We remember all too well what happened with the IEEE and WEP when cryptographers were not invited to participate and we would like to avoid any similar issues.)

The links for the ESAPI-2.0-rc6.zip file as well as separate source code are provided below. As you review things, please keep in mind that ESAPI was meant to be a general API. In particular, this means that not all enterprises have the same security policies so flexibility was required with respect to algorithms allowed, allowed cipher modes, permitted padding schemes, etc. Also allowing compatibility with legacy applications was considered important as well. However, we hope to have chosen reasonable defaults for things such that application developers who do not have issues with compatibility with legacy systems can use the ESAPI crypto configuration as-is without the need for tweaking anything other than the master key and master salt properties (which are left unset by default).

To comment on issues to this source code, email comments to Kevin Wall or post an issue on the ESAPI Issues List (see below).

Thanks to those of you have already help provided back in September and any future contribution you are able to make. If you would care to be acknowledged in some future ESAPI documentation for your contribution, please let OWASP know that as well, and if so, whether you only wish your name to be mentioned, or your name and email address.