This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Request to review ESAPI 2.0 crypto"

From OWASP
Jump to: navigation, search
m (Added reference to Google issue #120.)
m (Changes to reflect release of ESAPI 2.0-rc7, which fixed the padded oracle attack.)
Line 3: Line 3:
 
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 [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API Enterprise Security API (ESAPI)] 2.0 before this software package is considered generally available.  
 
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 [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API 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.  
+
The latest release candidate of OWASP's ESAPI for Java (ESAPI-2.0-rc7) 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 "[http://www.mail-archive.com/[email protected]/msg10889.html Detecting attempts to decrypt with incorrect secret key in OWASP ESAP]I" back in mid-Sept, 2009.) Specifically advice from David A. Wagner and Ian Griggs directly affected several of the detailed design decisions.  
 
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 "[http://www.mail-archive.com/[email protected]/msg10889.html Detecting attempts to decrypt with incorrect secret key in OWASP ESAP]I" back in mid-Sept, 2009.) Specifically advice from David A. Wagner and Ian Griggs directly affected several of the detailed design decisions.  
Line 13: Line 13:
 
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.)  
 
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).  
+
The links for the ESAPI-2.0-rc7.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 [mailto:[email protected] Kevin Wall] or post an issue on the ESAPI Issues List (see below).<br>  
 
To comment on issues to this source code, email comments to [mailto:[email protected] Kevin Wall] or post an issue on the ESAPI Issues List (see below).<br>  
Line 25: Line 25:
 
| '''Download ESAPI'''<br>  
 
| '''Download ESAPI'''<br>  
 
|  
 
|  
[http://owasp-esapi-java.googlecode.com/files/ESAPI-2.0-rc6.zip Download ESAPI-2.0-rc6 zip]  
+
[http://owasp-esapi-java.googlecode.com/files/ESAPI-2.0-rc7.zip Download ESAPI-2.0-rc7 zip]  
  
 
The source code is located is under 'project/src/main/java'. Note that the source code uses Maven 2.0 to build it, via the pom.xml file.<br>  
 
The source code is located is under 'project/src/main/java'. Note that the source code uses Maven 2.0 to build it, via the pom.xml file.<br>  
Line 59: Line 59:
 
|-
 
|-
 
| '''Javadoc'''<br>  
 
| '''Javadoc'''<br>  
| [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc6/index.html ESAPI Javadoc]<br>
+
| [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc7/index.html ESAPI Javadoc]<br>
 
|-
 
|-
 
| '''General documentation'''<br>  
 
| '''General documentation'''<br>  
Line 80: Line 80:
  
 
The crypto in ESAPI 2.0-rc6 is known to be vulnerable to a "padded oracle attack"
 
The crypto in ESAPI 2.0-rc6 is known to be vulnerable to a "padded oracle attack"
which is a type of chosen ciphertext attack designed to reveal plaitext.
+
which is a type of chosen ciphertext attack designed to reveal plaintext. We believe this is fixed in ESAPI 2.0-rc7 but it would be nice if someone who is a professional cryptographer could confirm this.
  
 
The details are provided at [http://code.google.com/p/owasp-esapi-java/issues/detail?id=120 ESAPI Google Issues list, issue #120].
 
The details are provided at [http://code.google.com/p/owasp-esapi-java/issues/detail?id=120 ESAPI Google Issues list, issue #120].

Revision as of 00:37, 18 September 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-rc7) 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-rc7.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.


Download ESAPI

Download ESAPI-2.0-rc7 zip

The source code is located is under 'project/src/main/java'. Note that the source code uses Maven 2.0 to build it, via the pom.xml file.

Code

(Approximately 3900 LOC or 1700 NCSL)

Relevant configuration properties (ESAPI.properties file): ESAPI.properties file


Interface (Encryptor): Encryptor interface


Helper implementation classes (CipherSpec, CipherText, CipherTextSerializer, CryptoHelper, PlainText, SecurityProviderLoader): Crypto helper classes

  • CipherSpec: All relevant data for using Cipher, except the SecretKey
  • CipherText: All the CipherSpec data, plus the ciphertext from encrypting
  • CipherTextSerializer: Helper class to assist with portable serialization of CipherText objects.
  • CryptoHelper: Static helper methods.

Of these, the method I want to see inspected above all others is
     public static SecretKey computeDerivedKey(SecretKey keyDerivationKey, int keySize, String purpose)
Implementation (JavaEncryptor):


JavaEncryptor class
We welcome feedback on all methods, but please focus on the *symmetric*
encryption / decryption methods (all named encrypt() / decrypt()) in this class.

Javadoc
ESAPI Javadoc
General documentation
Describes reasons of why we are changing the ESAPI symmetric crypto for ESAPI 2.0

Description of the portable serialization of CipherText objects
User Guide for Symmetric Encryption in ESAPI 2.0

ESAPI Issues List
Google Issues List
Requires Google account to submit new issues.
Note that issue # 81 is a request to review the computeDerivedKey() method in CryptoHelper. You may comment on this issue or add your own if you find defects by first logging in using your Google account.






Known Relevant Issues

The crypto in ESAPI 2.0-rc6 is known to be vulnerable to a "padded oracle attack" which is a type of chosen ciphertext attack designed to reveal plaintext. We believe this is fixed in ESAPI 2.0-rc7 but it would be nice if someone who is a professional cryptographer could confirm this.

The details are provided at ESAPI Google Issues list, issue #120.