[OWASP-ESAPI] [Fwd: AES 256-bit vs. AES 128-bit in ESAPI]
Kevin W. Wall
kevin.w.wall at gmail.com
Fri Aug 21 01:02:28 EDT 2009
Good comments. Here are my thoughts on what you write about.
Boberski, Michael [USA] wrote:
> I've been watching this and similar threads, maybe time to jump in.
Sooner is usually better than later.
> ESAPI is over-reaching, trying to include crypto, in general. I think
> these discussions are further going sideways by even further over-reaching
> by attempting to include PKI functionality, with the mention of OCSP
> below. Repeated mention of advice to use for example BouncyCastle is
> plain BAD advice.
So, would it surprise you if I told you that I pretty much agree with you?
Especially wrt to public key crypto.
I got interested in ESAPI because I liked the various codecs and
some of the other stuff and thought it would be a great fit for our
Then I took a look at Encryptor and JavaEncryptor and I thought, no
way can I bring this into our company. Wny not? Because if I did,
all the developers would soon be using ESAPI for encryption doing
String ciphertext = ESAPI.encryptor().encrypt("my plaintext msg");
String plaintext = ESAPI.encryptor().decrypt(ciphertext);
and soon we'd be back to the horrid state that I found the company in
10 years ago where everyone was just copying and pasting bad examples
using ECB mode from the Internet and using it without having a clue
as to what's wrong with it.
So at that point, I could either throw out the baby with the bath
water and forget about using ESAPI at all (or do a special build
without any crypto stuff, but that would only work until some
discovered they could download it themselves, and "hey, there's
this really cool, easy to use crypto with it") or I pitch in and
see if I could get the symmetric encryption in a tolerable state
for the 2.0 release. It's not going to be great, but I'm hoping to
at least make it minimally usable. Also, I'm striving to create it
in such a way that the interfaces will allow another stronger
implementation (than the reference implementation) to be substituted.
(The one I have in mind is one our team has developed for the past 10+
years in my day job. Unfortunately proprietary.)
> Go check out the US Marine Corps' PKIF toolkit on
> SourceForge, see how hard it is to do a PKI toolkit right.
Not a fair comparison. Almost everything is harder to do in C++ than
in Java. I spent 15+ years coding in C++ at Bell Labs until I
arrived at my present position and started using Java almost exclusively.
As I mentioned to Jim Manico, if I had to take a job doing C++ instead
of Java (or C# or Groovy etc.) I probably would automatically want to
charge $50/hr extra for pain and suffering. (Bjarne will never forgive
me for that one! ;-)
> I would NEVER use non-FIPS 140 validated code to provide crypto. I would
> also never use a non-FIPS 140 validated PKI toolkit, nor bless an
> underlying container's non-FIPS validated TLS implementation. These are
> items where I'm going to draw a hard line in my own use of ESAPI on
> customer engagements. Most 140-validated modules have a hard enough
> time working correctly let alone any non-FIPS modules, and are
> extraordinarily delicate once they are TECHNICALLY CORRECTLY
> installed/configured/operating in FIPS mode.
Technically, that would be FIPS 140-2. FIPS 140-1 is now obsolete I think.
However, I think that until things like SOX, NACHA, PCI DSS, HIPAA, etc.
mandate FIPS 140-2 crypto, then *most* companies are NOT going to
spring for them. (Understand that these are the same companies who
likely wouldn't even BE ENCRYPTING sensitive data at all if it were not
for such mandates and regulatory issues.)
Working for Booz Allen, you may have the luxury of working with many
US federal government institutions or companies who contract with the
US federal gov't so FIPS 140-2 compliance can be mandated. But as
much as we wish they would, not all companies are going to license
such crypto. And besides, even if they would, it's not clear that
there developers are going to USE that crypto correctly.
BTW, I could be wrong about this, but I think that RSA's Crypto-J
(aka, JSafe) was validated to at least FIPS 140-1 and maybe 140-2
(it's been a long time since I looked) and JSafe has a JCE compatibility
And for the record, I think that the OpenSSL team also finally were
validated to FIPS 140-2 just so people on this list dont think
one has to pay for all FIPS 140-2 compliant software.
And as far as it goes, Peter Guttman's cryptlib is excellent and
probably could get validated to FIPS 140-2 if he were willing to
jump through all the required hoops or someone payed him to fund
> Keeping a wrapper for things like authentication is fine, that's
> kind of a toss-up whether it's usable. Really need to stay focused
> on features and functions that are unique to the IDEA of an ESAPI,
> and the IDEA of ES-Enabling applications, and make those core
> functions easily used and reusable. Work on standardizing and
> stablizing these things.
But as far as that goes, why not a wrapper for crypto? I would
contend that even if you used something like RSA's Crypto-J
or OpenSSL or anythng else that you want that's been FIPS 140-2
validated, there would still be a significant portion of application
developers who are going to use it wrong. I've spent the last 10+
years on an application security team consulting about security-related
topics with application development teams plus 5 years teaching a
master's level computer security course in CS. My experience is that
most developers wouldn't know CBC from ECB, have no idea of what
padding schemes are or what you should use one, and have never heard
of an initialization vector. So give those people your FIPS 140-2
validated software and see where it gets you. As they say, a fool
with a tool is still a fool.
That said, there has to be a happy medium. Personally, I have no
intention to add any PKI functionality to ESAPI Java 2.0. At least
not unless I discover that its present in ESAPI Java 1.4 and totally
messed up there as well; but so far, I've not run across it. There's
a CertificateException class, but I haven't seen it being used anywhere.
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
More information about the OWASP-ESAPI