Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green
From: Kevin W. Wall on 15 Feb 2010 19:14
The Open Web Application Security Project (OWASP) is a 501(c)(3)
not-for-profit worldwide charitable organization focused on improving
the security of application software and all of OWASP's materials are
available under a free and open source software license.

The next release candidate of OWASP's Enterprise Security API (ESAPI)
for
Java (ESAPI-2.0-rc5) has recently been released. This is the first
complete
release candidate that cotains the completely revamped symmetric
encryption.

Many of these changes to OWASP's symmetric encryption came about as a
result
of the suggestions of many of you on this mailing list. (See thread
"Detecting attempts to decrypt with incorrect secret key in OWASP
ESAPI"
back in mid-Sept, 2009.)

Because the OWASP ESAPI team is interested in getting the symmetric
encryption
portion correct this time, we are solicting cryptographers and anyone
else
with an interest to comment on the implementation and documentation.

In particular, I personally 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.

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-rc5.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 somewhat important as well. However, we hope to have
chosen reasonable defaults for things such that application developers
that do not have issues with compatibility to legacy systems can use
the configuration as-is without the need for tweaking anything other
than the master key and master salt properties.

You may provide feedback via email personally to me or on-list. If you
would care to be mentioned in some future ESAPI documentation for your
contribution, please let me know that as well, and if so, whether you
only wish your name to be mentioned, or your name and email address.

Thanks for the help you have already provided back in September and
any future contribution you are able to make.

Regards,
-kevin wall

==================== Relevant ESAPI Links follow ====================

Download zip (source is under 'project/src/main/java'):
<http://owasp-esapi-java.googlecode.com/files/ESAPI-2.0-rc5.zip>
The source code uses Maven 2.0 to build, via the pom.xml file.
NOTE: The documentation referenced below is *newer* than the
documentation provided in this .zip file.
Code:
Relevant configuration properties (ESAPI.properties):

<http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/
resources/.esapi/ESAPI.properties>
Interface (Encryptor):

<http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/
owasp/esapi/Encryptor.java>
Helper implementation classes (CipherSpec, CipherText,
CipherTextSerializer,
CryptoHelper, PlainText,
SecurityProviderLoader)

<http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/
owasp/esapi/crypto/>
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):

<http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/
owasp/esapi/reference/crypto/JavaEncryptor.java>
Welcome feedback on all methods, but please focus on the
*symmetric*
encryption / decryption methods (all called encrypt() /
decrypt()).
Javadoc for ESAPI-2.0-rc5:
<http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc5/
index.html>
General documentation:

<http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/
esapi4java-core-2.0-readme-crypto-changes.html>
Describes reasons we are changing the ESAPI symmetric crypto
for 2.0

<http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/
esapi4java-core-2.0-ciphertext-serialization.pdf>
Description of the portable serialization of CipherText
objects

<http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/
esapi4java-core-2.0-symmetric-crypto-user-guide.html>
User Guide for Symmetric Encryption in ESAPI 2.0
Issues list (Requires Google account to submit new issues):
<http://code.google.com/p/owasp-esapi-java/issues/list>
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.

-kevin
-- Kevin W. Wall "The most likely way for the world to be destroyed,
most experts agree, is by accident. That's where we come in; we're
computer professionals. We cause accidents." -- Nathaniel Borenstein,
co-creator of MIME
From: Paul Rubin on 16 Feb 2010 00:59
"Kevin W. Wall" <kevin.w.wall(a)gmail.com> writes:
> The next release candidate of OWASP's Enterprise Security API (ESAPI)
> for Java (ESAPI-2.0-rc5) has recently been released.....

I'm way behind the times but I thought Java already had a working crypto
API (JCA/JCE) which included a full TLS stack (JSSE). Why not use it?
From: Globemaker on 16 Feb 2010 15:01
I am available to review your crypto code if you are a citizen of the
USA and will prove that to me, and you pay me $3000 per week for ten
weeks. I do not expect you to get any better offers. Thank you, Alan
Folmsbee, Kona, Hawaii, USA
From: Kevin W. Wall on 16 Feb 2010 21:10
On Feb 16, 12:59 am, Paul Rubin <no.em...(a)nospam.invalid> wrote:
> "Kevin W. Wall" <kevin.w.w...(a)gmail.com> writes:
>
> > The next release candidate of OWASP's Enterprise Security API (ESAPI)
> > for Java (ESAPI-2.0-rc5) has recently been released.....
>
> I'm way behind the times but I thought Java already had a working crypto
> API (JCA/JCE) which included a full TLS stack (JSSE).  Why not use it?

Java has some decent API with the JCE and JSSE. The problem with them
is that almost every novice uses them naively. For example, almost
every
example that I've seen that's been written in instructions on the web
uses
ECB cipher mode which as you are probably aware, very weak, especially
for general use. The average developer doesn't know about cipher
modes, IVs,
padding schemes, etc. The goal of this development was to provide
something
that was secure that could easily be used by a developer with no
previous
knowledge of cryptography.

Hope that answers your question.
From: Kevin W. Wall on 16 Feb 2010 21:42
On Feb 16, 3:01 pm, Globemaker <alanfolms...(a)cabanova.com> wrote:
> I am available to review your crypto code if you are a citizen of the
> USA and will prove that to me, and you pay me $3000 per week for ten
> weeks. I do not expect you to get any better offers. Thank you, Alan
> Folmsbee, Kona, Hawaii, USA


Perhaps I was not clear...if so, my apologies. But OWASP is a 501(3)
(c)
charitable organization. Almost all of its workers are non-paid
volunteers who freely commit their time. OWASP has no $$ to pay
anyone. If
one includes all the interactions via emails and phone calls, I alone
put in well over 250 hours on this effort and several others
contributed
as well. All of us did this with no reward other than the satisfaction
that knowing we were giving back to society.

In addition, all this source code is being released under a BSD
license,
so anyone can use it even without contributing back to it if they so
desire.

If you don't want to volunteer your time, that's fine. We are hoping
that a few noble cryptographers out there will step up and volunteer a
few hours. Perhaps those teaching a cryptographer course can make it a
class assignment for their students and they oversee the results. We
only
are trying our best to avoid the fiasco that the IEEE found themselves
in
when they wrote the specifications for WEP as part of the 802.11
specs.
I do not consider myself completely clueless wrt cryptography, but
it's
doubtful that the IEEE did either. So we thought it important to
invite
cryptographers to the party.

BTW, the total # of LOC (including comments and white space) is ~3300
LOC and roughly 35-40% of that is comments and blank lines.
Therefore,
it's very unlikely to take anyone ten weeks to review such code. Even
at a very modest pace of only 50 LOC reviewed per hour, that only
amounts
to 66 hrs. Of course, you had no way of knowing how much code there
was
unless you looked--and perhaps I should have mentioned it--but I felt
that the post was a bit on the lengthy side already.

Again, I apologize if I mislead you into thinking this was a task that
OWASP was willing to pay for. Sorry to disappoint you on that front.

Sincerely,
-kevin wall
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green