[Esapi-user] [Esapi-dev] Call for review of crypto code
Kevin W. Wall
kevin.w.wall at gmail.com
Fri Apr 30 09:24:11 EDT 2010
Boberski, Michael [USA] wrote:
> I do have one general comment that's basically just a reiteration
> of previous proposals to basically further wrap the crypto,
> it occurred to me again yesterday as I was reviewing existing
> documentation and working on consolidating and extending it in
> http://code.google.com/p/owasp-esapi-java/wiki/Welcome , if you look
> inside the ESAPI for Java distribution in " \ESAPI-2.0-rc6\documentation",
> the amount of documentation for Encryptor is much more than for any other
Well, I think one reason for that--the main reason, in fact--is that
other ESAPI developers have not bothered to complete documentation.
I think the understanding was that we first were going to complete
the OWASP Dev Guide and then drive examples / documentation for
ESAPI for Java out of that.
> (1)Other ESAPI controls aren't as hard to use, (except maybe
> the WAF which is a separate thread), and
I think that is a matter of opinion. I someone just wants to use
the "out-of-the-box" ESAPI.properties settings, coding is pretty
straight forward--*assuming* (and this is a big assumption) that
the developer knows when to use encryption vs. digital signatures
vs. hashing, etc. That is something that I didn't address in the
docs I wrote. That was the part I figured would be placed into
the OWASP Dev Guide and we would just reference from the ESAPI
for Java documentation / Wiki.
Certainly other ESAPI controls (with the exception of WAF) do
not have as many options that someone may need to tweak. But it
was a balancing act between providing flexibility vs. ease of
use. I approached it by providing lots of properties to be tweaked,
but also by giving them all reasonable defaults that 80% or so
of the development community will be able to live with. (Note:
IMO, this is not the forum to debate the default settings of
the individual properties. If we want to do that, let's sit down
and review all of them at once. I have always been open to
code inspections, etc.)
> (2)none create proprietary
> (non-standards-based) outputs, for Encoders for example we code to
> e.g. MySQL specs, why don't we do something similar, like use PKCS#7 or
> CMS here.
This was considered and dismissed. (Well, more specifically CMS was
considered and dismissed. CMS was originally more or less an extension
of PKCS#7 v1.5 and I saw no point going backward.)
There were several reasons why I decided against this. I'll
start a new thread on these lists shortly after this email,
but I don't want to get this thread off on a tangent so I
am not going to discuss it any further here. Watch for a
new subject of "Why ESAPI crypto uses a custom serialization scheme",
coming soon at an ESAPI list near you.
> Also, why does ESAPI care how a crypto algorithm is implemented,
I totally don't understand that statement. ESAPI only interfaces
they crypto algorithms though the JCE interfaces (such as Cipher,
for instance). There are multiple implementations of that possible
as long as they adhere to that interface. For instance, I have
tested against both SunJCE as well as Bouncy Castle implementations.
So please be more specific and explain yourself here.
> I really don't think we want to try to stand behind algorithms, we're not
> the open crypto project, we're just a wrapper that uses things according
> to best practices, FIPS 140 or no for example. It's our use of algorithms
> and key management that we should solicit reviews of.
I completely agree with this and have been saying this all along. In fact,
IMO (and I now think I've convinced Jim after months of arguing) that
ESAPI really does not do key management at all...or at least it does
not do it at all. ESAPI's idea of key management is to store the
secret encryption key in the ESAPI.properties file and then rely
solely on the OS file system protection mechanisms to keep unauthorized
people from taking a peek. (Yeah, that will work well, for about
2 weeks, until someone starts emailing the ESAPI.properties file around.)
That's why Chris Schmidt and I were arguing that we should at least split
the Encryptor.MasterSecret and Encryptor.MasterSalt into a separate
ESAPI property file. It's also why I thought we better provide an
Encryptor encrypt() / decrypt() interface methods that allowed a
SecretKey to be passed. That at least allows us a mechanism to hook
in a place for key management in the future.
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