[Esapi-user] Analysis of ESAPI 2.0's Key Derivation Function

Kevin W. Wall kevin.w.wall at gmail.com
Tue Jan 11 21:08:26 EST 2011

[Apologies for the x-post, but I think the pros outweigh the cons here.]


I have created Google Issue #198 to track the status of changes that I
intend to make as a result of the NSA's crypto review as well as
Jeff Walton's excellent analysis of ESAPI 2.0's Key Derivation
Function (KDF), CryptoHelper.computeDerivedKeys().  This method is one of
the cornerstone's of ESAPI 2.0's symmetric encryption, used whenever the
property "Encryptor.CipherText.useMAC" [1] is set to "true" (the default)
in ESAPI.properties file and the selected cipher mode does not already
provide authenticity. Thus it is critical to get it correct and
secure and both Jeff and the NSA had something to say about it.

While we are awaiting official word from the NSA as to whether we can
*publicly* post their comments that they finally made available to us,
I wanted to make Jeff Walton's critical analysis (and I mean that in a *good*
way) of ESAPI's KDF (whose review was requested in Google Issue #81) available
to all for comment. I have attached his report in PDF format to Google
Issue #198. However, if you wish a direct link, you can find the PDF here:

*So let your [INFORMED!] comments begin. I would ask if you are not familiar
with the subject matter being discussed, please take the time to research it
first by perusing the references in Jeff's document before responding.*

Also, if you presently are using ESAPI's symmetric encryption with some
ESAPI 2.0 release candidate and using it *to persist encryption data*,
please YELL NOW or forever hold your peas (& carrots). Summarize what
ESAPI version you are using, what exact ESAPI crypto-related classes you
are using, and most importantly provide an estimate of the potential hardship
you would encounter if you have to decrypt and re-encrypt all your data.
If this adversely affects enough ESAPI users, then it is possible we _may_
(no promises though) reconsider and address the backward compatibility issue
in the GA version of ESAPI 2.0. (More on that in a future post, probably

*NOTE*: If you prefer your feedback NOT go to the list(s), I ask that you at
least CC: Jeff Walton & myself. Most of the recommendations that Jeff Walton
makes are easy to implement (as long as backward compatibility with previous
2.0 release candidates is not required; see [2], below), so that is the path
that I plan to follow. However, given that it is not clear how adding NIST's
"Context" argument would fit into the current architecture, I plan on ignoring
that part of Jeff's recommendation until at least ESAPI 2.1 as it would add
significant complexity which I do not wish to introduce at this point until
I have time to better evaluate our options. Following NSA's recommendations
has other trade-offs which I shall also attempt to address in my next post
on this topic.

So let the feedback begin. Thanks!
[1]  It should be set to "false" when you are using ESAPI 2.0 crypto with a
     FIPS 140-2 certified JCE provider. See ESAPI.properties for details.
[2]  By that, I mean the interface to CryptoHelper.computeDerivedKey() would
     change, thus *any previously persisted encrypted data creating using any
     previous ESAPI 2.0 release candidate would have to be decrypted using
     the previous RC ESAPI library and then re-encrypted using the ESAPI 2.0
     library.* However, it would not require regenerating secret keys, such as
     Encryptor.MasterKey, or other code changes (unless perhaps you are using
     CryptoHelper.computeDerivedKey() directly). If you are able to simply
     discard previously encrypted data and re-encrypt it using ESAPI 2.0, you
     would not need to do anything. Such backward compatibility issues will be
     taken very seriously once ESAPI 2.0 is made GA, hence the need to get this
     correct *now*. There is also an NSA issue to address that has a similar
     affect. I will explain both of these things in more detail in a follow
     up post within the next day or two.
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