[OWASP-ESAPI] New ESAPI Java 2.0 encryption code committed to 2.0_quality branch

Kevin W. Wall kevin.w.wall at gmail.com
Tue Aug 25 01:34:18 EDT 2009

All OWASPI ESAPI developers...

Had discussion w/ Jim Manico (see below) and he was in favor of me getting these
changes for the new ESAPI 2.0 encryption code committed ASAP even though I have
barely started unit testing. (I will try to start that tomorrow.)

However, Jim and I are looking for volunteers to assist with a code inspection.
It probably would be helpful if you know some basic cryptography, but that is
not required.

I will leave it up to Jim to select representatives from those among you who
volunteer--that way I will not unknowingly introduce any bias, etc. So if
you are interested in participating in a code inspection of the new ESAPI
encryption code, please contact Jim Manico and I'll leave it to him to
arrange the logistics of the inspection. I imagine that we might want
to use one of those free conference calling sites such as FreeConferenceCall.com

At the very end of this email--if you are interested--is a summary of all the
commits that I did in relation to this code. There is about 20 or so files in

Also please at least read through the thread below so you will understand why
I have not yet unit tested this code. It's not (just) because I'm lazy. ;-)

-kevin wall
P.S.- I am seeing what can be done to stage a version of the Javadoc for those
      of you who are more ESAPI users rather than developers and who wish to
      take a look at what this is like. Jeff, Jim: Is there somewhere we can
      put this up at either owasp.org or at Google Code,
      http://code.google.com/p/owasp-esapi-java/   ???

Jim Manico wrote:
> I'm in support of this methodology - I think GROUP code review like you
> describe is the perfect way to go. Encryptor one review sounds reasonable.
> I'm especially a fan of "test last coding" - test first is a nice theory
> but is also a huge time hit.
> So let's Rock! I want to be in on this code review....
> ... very glad this is all working out so well!
> Jim Manico
> On Aug 23, 2009, at 11:07 PM, "Kevin W. Wall" <kevin.w.wall at gmail.com>
> wrote:
>> Jim,
>> Just wanted to let you know where I am at. I did a bit of refactoring
>> of things
>> which simplified some stuff a bit and also allowed me to support
>> encryption /
>> decryption with a specified SecretKey rather than just using the
>> master key.
>> (Using the master key is just a special case of this.)
>> I pretty much have everything written EXCEPT JUnit tests. That
>> probably will
>> take another 6-8 hrs or so.
>> Usually, at Qwest, we do our code inspections BEFORE writing / running
>> all
>> the JUnit tests so we can get the biggest benefit from the many eyes
>> looking
>> at the code. If one is humble enough to accept others pointing out the
>> obvious
>> flaws in your code, then one can benefit from them finding the bugs so
>> you
>> don't have to spend as much time debugging your code while testing it.
>> So... I was thinking of approaching it this way, but let me know your
>> thoughts.
>> I figure I'd commit all the code that I have changed to the
>> 2.0_quality branch
>> and then try to schedule 2 to 4 others for code inspections. (I figure
>> two is a
>> minimum, and 4 others is probably a max, since w/ me that would make
>> 5. However,
>> I'm willing to do it "the OWASP way" if you have some inspection
>> process you
>> generally use.)  At Qwest, the roles that we have are a reader
>> (usually the
>> author), a moderator, a scribe, and N inspectors and usually try to
>> keep the
>> total # of participants to <= 5 and we usually try to hit an
>> inspection rate
>> of between 150-200 non-commentary source LOC / hour. But, like I said,
>> if OWASP
>> as a different way, we can do it the OWASP way. NP with that.
>> Anyway, my preference would be to commit my changes, then schedule
>> inspections
>> while continuing to write JUnit tests. I would then fix things that as
>> I find
>> them, but would not necessarily commit those changes unless you think
>> it would
>> be beneficial or unless the changes are major. (Could let those
>> planning on
>> participating in the inspection that changes were made and let them
>> rule on
>> whether I should commit those changes too. If they hadn't started
>> reviewing that
>> particular code, that probably would be the best approach.)
>> Anyhow, let me know how to proceed from here. Shall I commit changes,
>> how to
>> schedule the inspections, etc.?
>> Thanks,
>> -kevin
>> P.S.- Also, assuming you have already inspected the 1.4 baseline code,
>> do we
>>      only want to inspect the changes for things line Encryptor or
>> reinspect
>>      everything? That makes a big difference in how much time we need to
>>      schedule.
>> -- 
>> 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

======================== Summary of Commits =========================

    Tried to fix jar signing. Still needs lots of work. See comments therein.

    New file -- Explains why we are making changes to the Encryptor encrypt /
decrypt methods in ESAPI Java 2.0 and gives some examples of use.

    New; a Java keystore file with a self-signed cert to be used for jar signing
the ESAPI 2.0 jar.

    Summarized crypto changes, added new properties to support new Encryptor
encrypt / decrypt methods, briefly explained backward compatibility for Encryptor.

        CipherText - Untested! Made Serializable, added several new methods,
flushed out Javadoc
        Encryptor - Flushed out Javadoc. Added 2 new methods (encrypt() and
decrypt() that take a SecretKey).
        ESAPI - Added some comments for discussion (marked 'DISCUSS').
        PreparedString - Fixed Javadoc so it wouldn't prematurely die.
        Randomizer - `Added new method, getRandomBytes(int n).
        SecurityConfiguration - Fixed misc Javadoc, added several new mthods to
support new Encryptor encrypt / decrypt methods.

        Hex - New class to do hexadecimal encoding / decoding.

        DefaultCipherText - Untested! Completed implementation and Javadoc.
        DefaultRandomizer - Untested! Implemented new gentRandomBytes(int) method.
        DefaultSecurityConfiguration - Untested! - Implemented new methods to
support new Encryptor encrypt / decrypt methods, Javadoc corrections.
        JavaEncryptor - Untested! Lots of Javadoc changes. Implemented 2 new
encrypt() and 2 new decrypt() methods.

        CipherSpec - Untested! New class. A Serializable class that carries all
info about a specific cipher specification that was used to encrypt some
particular ciphertext (other than the SecretKey of course). Main intent is to be
used with CipherText, but may be used alone.
        CryptoHelper - Untested! New class. Some static methods to simplify
encryption and decryption of plaintext Strings, to be used as a replacement for
the deprecated Encryptor encrypt() and decrypt() methods if ESAPI users find the
newer methods too inconvenient to use.
        ObjFactor - Mostly tested (except for one or 2 'catch' clauses). Fixed
some Javadoc. Made CTOR public (probably is a way to just do this using a static
method, but it wasn't obvious and I didn't want to screw with it). Improved some
internal documentation. Added OWASP copyright notice.
        StringUtils - Added new notNullOrEmpty() method used in assertions.

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 mailing list