[Esapi-user] [Esapi-dev] ESAPI 2.0 production status

Kevin W. Wall kevin.w.wall at gmail.com
Wed Jan 12 21:41:47 EST 2011


On 01/12/2011 06:41 PM, Mike Boberski wrote:
> Hi,

Hi Mike. Glad to know you're still involved and interested.

> What is the result / goal of this NSA review?

Well, I won't attempt to speak for others, but as the author
of the ESAPI 2.0 crypto, my goal was pretty simple:

	To prevent me from doing something totally (but
	unintentionally) stupid that would result in
	current or future security issues.

I was concerned that I omitted something important, or maybe overlooked
something. Crypto is hard and subtle and there's not a lot of people with
both deep crypto knowledge and coding expertise that have the time to
help. (Translation: Good help is hard to find. Good free help is even
harder.)

As to the result, well, I wouldn't say there was anything earth shattering.
NSA wanted one log message to print all the time (it was set to INFO
because it really was informational, but since it is more of an audit message,
we will do something to address that). They wanted HmacSHA1 in
computeDerivedKeys to ideally be selectable, but at least replaced with
a SHA2 HMAC like HmacSHA224. They pointed out the fact that the pub/priv keys
which are generated and used for signing are never persisted, which I was
already aware of, but chose not to address until ESAPI 2.1. They mentioned some
things that they liked also.  I'd like to be more specific, but we are waiting
to get the green like to post it verbatim to the OWASP wiki.  But bottom
line, nothing earth-shattering revealed. (Of course there are some out there
who are going to think, if they found something non-obvious that seriously
weakens the crypto, do you think they are really going to tell you?  Of course,
there is no way to respond to that and there is no way to know either, so
those sorts of hypothetical questions are really pointless, aren't they?)

> Will this result in a specific version of ESAPI being:
> 
>    - CMVP/CAVP FIPS 140 validated, and/or
>    - NIAP CC validated, and/or
>    - Entered into some "NSA approved" registry,
>    - Etc.

I'd guess, "none of the above". Well, maybe 'Etc.' depending on how
you define it. It gave me a certain amount of warm fuzzies that I didn't
totally muck things up, but that's about the extent of it. That and
$1.25 will get you a cup of coffee.

> Are there plans to get ESAPI re-reviewed after all of these changes to
> address NSA questions, to ensure addressed to their satisfaction?

I know it's hard to give you assurance regarding this having not read
the NSA findings, but I'm pretty confident that any security engineer
worth their salt and knowing how to code their way out of a wet paper
bag should be able to do this, that is to check that the changes I make
address the NSA concerns.

> Will non-NSA e.g. Walton changes be reviewed by NSA to ensure they
> don't undo NSA analysis?

That too should be pretty simple and I don't think that we need to worry
about it. If you read Jeff's report, he was only making some recommendations
that we adhere a bit more closely to NIST SP 800-108, so that's what I
did / am doing. We were almost there, but not quite. The apparently
optional 'Context' parameter in the NIST KDF's is what is difficult to
see how it fits into the current ESAPI framework. I think we might have
to radically alter the Encryptor interfaces supporting symmetric encryption
to support that correctly and in addition it would had a sizable about of
overhead in the MAC when encrypting.

Of course, there's always the possibility that my changes (or any changes,
for that matter) could "undo the NSA analyss", but hopefully, now that we
have a reviewed baseline, people can review the diffs and judge for themselves
without being a crypto expert. At least that's my hope, as foolish as
it may be.

> Where will all NSA analysis and responses be posted so that claims of
> working with them and so on may be independently verified by consumers? This
> is not a flip question, certain people / segments of the population may be
> concerned that e.g. back doors are somehow being engineered in.

Ah, seems that no one trusts the NSA. ;-)

Chris Schmidt or I will post it somewhere on the OWASP Wiki, complete
with all email headers. I also suggested that one of us sign it with
our PGP key so that no one can alter it without future detection (or
compromise of our private key; mine's for sale for a case of Guinness :-).

If someone is into conspiracy theories though, I doubt if that will help.
I mean, the NSA did not PGP sign their original "report" (it was simply
an email back to us describing the "issues"), so there's no guarantee that
we did not alter it first, right? You will have to trust us and that
we did not sell out to the NSA for motherhood and apple pie. (Motherhood
is overrated and I'd never sell out for apple pie--peach pie, maybe, but
never apple! ;-)

> How will users know they are using the blessed / certified version?

There is a plan for the ESAPI 2.0 GA for someone on OWASP to sign the
ESAPI jar and provide the signing cert somewhere so it can be validated
against that. (Well, that, plus if your use of ESAPI stops emailing me
all your secret keys, I'll know you are using the wrong version. JK)

> How will they know they are using it correctly?

If I could solve *that* problem, I'd be rich because I'd likely be able to
tell if they are using any other API correctly as well. And if we knew that,
frankly ESAPI wouldn't be 1/2 as useful as it otherwise is.

> Is NSA blessing not just the crypto but all of ESAPI?

"Blessing" is a rather strong word. Do not think of this as an "endorsement"
of any kind, but rather as a "sanity check" of the code doing what it is
intended to do.

Having said that, yes, they are looking at other aspects of ESAPI. That feedback
is not yet available, and we didn't wish to hold up ESAPI 2.0 GA for that long.
Besides, I think there are lots of non-crypto security experts out there who
have weighed in on the other aspects of ESAPI, so personally, my confidence in
other parts of ESAPI is much higher than it is/was with the crypto code. (I
keep telling folks that *I am not a cryptographer*, but somehow that message
is not getting across. I suppose expertise is relative, but compared to real
cryptographers whom I monitor in a few crypto mailing lists, I am but a newb.)

> What specifically are they standing behind with their
> review and recommendations?

You will have to ask them, or wait until it is finally posted (which I am sure
we will announce) and decide for yourself.

Again, don't think of this as an endorsement for ESAPI. I personally hope that
no one tries to spin it as such. IMHO, at best, the conclusion that you can
draw is that ESAPI's crypto is not obviously broken to the crypto experts who
reviewed it. (Unless you are into conspiracy theories, in which case, I'd
advise you to don you tinfoil hats and simply avoid ESAPI crypto. ;-)

> ESAPI's a mix of toys and tools, and more toys
> and tools than just cryptographic security functions.

Thus far, we've only received feedback regarding the ESAPI crypto. Hopefully
more feedback of the other ESAPI "toys" will soon follow.

> Many more questions along those lines. Maybe let us start here though. The
> questions are from the perspective of a prospective adopter who has
> requirements to use one or more of: CC validated, FIPS 140 validated, or NSA
> approved cryptography.

If you really want to use ESAPI crypto for this, then I suggest that you
carefully read through the section "Using ESAPI Symmetric Encryption with
FIPS 140-2 Cryptographic Modules" in the "ESAPI 2.0 Symmetric Encryption
User Guide" at
<http://owasp-esapi-java.googlecode.com/svn-history/r1672/trunk/documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html>
(Sorry, should probably have had internal named tags to xref the sections.
I don't so you'll have to search for it.)

This more or less describes a way to use some of ESAPIs crypto but to keep it
out of the way of your FIPS 140-2 validated JCE crypto provider.  If you are
looking for something else, such as ESAPI itself being certified, I don't see
that as likely unless some company is willing to fund it. It supposedly took
the OpenSSL folks 4 years to get this, so the OWASP community would have to
ask is it really worth it. If someone really wants it and wants to sponsor
it, I'll help in whatever manner that I can, but absent from that, I think
there are other more important priorities for me to address in ESAPI.

Or just use some FIPS 140-2 certified JCE provider directly rather than
using ESAPI. If you stick to a NIST approved cipher mode that also provides
authenticity such as CCM or GCM you should be pretty safe. If you use CBC,
than be sure to implement a MAC using an Encrypt-then-MAC approach using
the FIPS 140-2 approved KDF to derive keys that your vendor likely provides
(or they don't, use 2 completely separate, independent keys--one for
confidentiality and one for authenticity). In such cases, ESAPI might not
be your best choice for such things. (There are other tools in the
tool shed.)

> Please keep in mind I'm trying to help.

I never took it any other way. Your comments both now and in the past
have helped me and to make ESAPI a better product.

> OWASP needs a much stronger productization function that it currently has;

That be true. If I worked in a QA dept, I'd probably give ESAPI a 'C'. I think
there's a lot more tests that could/should be written, especially using mock
interfaces. If you look at the test coverages, you can clearly see that as
an area of need. It is a work in progress. I think we could also use some
help on the documentation front.

> right now ESAPI is all I care about in terms of trying to help figure things out.

If you can spare the time, we could still use your assistance to improve the
documentation, to review code, to write more JUnit tests to get more code
coverage, etc.

Anyway, thanks for your thoughtful feedback.
-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


More information about the Esapi-user mailing list