[Esapi-user] [Esapi-dev] Working with ESAPI.Encryptor

Kevin W. Wall kevin.w.wall at gmail.com
Sat Mar 17 21:58:15 UTC 2012

On Sat, Mar 17, 2012 at 6:25 AM, Jörg Liedl
<joerg.liedl at student.htw-berlin.de> wrote:
> Hi Kevin,
> thank you for your really fast support, thanks!!

Had to help. Was worried that you might have found a bug
in my code! ;-)

> you wrote:
>  Encryptor.cipher_modes.additional_allowed=CBC
> and this was absolutely not in my ESAPI.PROPERTIES file...
> so i downloaded now a new esapi.properties file, and changed it into my
> configuration and it worked!

Great; glad it was that simple.

> Ok, you told me to use the not deprecated version, I understand this!
> Is this the correct way to do it?
>        CipherText testEncrypt = ESAPI.encryptor().encrypt(new
> PlainText("stringToEncode"));
>        PlainText t = ESAPI.encryptor().decrypt(testEncrypt);
>        String x = new String(t.asBytes());

That's the acceptable way, assuming that you are willing
to use the ESAPI.MasterKey. The problem with that is you have no
no control over a way to predicting the secret encryption key.
I personally prefer to use Encryptor.encrypt(SecretKey, PlainText)'
that way you can pull out your SecretKey and secure it in a PKCS#12
key store and protect it with a passphrase. Of course, you have to
write that code yourself, but it's not that hard. I didn't want to add
a bunch of stuff late because of the NSA review, but I suppose I could
write it up and add it to the 'contrib' section.  The other major
advantage is that it allows you to use different keys with different

I'm hoping that for ESAPI 3.0 we will have a rewrite of the ESAPI
configuration and come up with a better way to secure things, but don't
know what that is yet.

> in my ESAPI.PROPERTIES was something from FileBasedAuthenticator2, a file i
> couldn't find in my Esapi (i work with 2.0.1 - which i get by maven)
> so i had to change it by hand to FileBasedAuthenticator without the 2
> i think i copied my properties file from my working Swingset example ....
> (it was esapi 2.0.rc4 i think!)
> thanks for showing my the error!

Yeah, that Encryptor.cipher_modes.additional_allowed property
wasn't added until a bit later.

> By the way: is this list the right one for questions like this, or the esapi
> user list??

The ESAPI user list probably would have been the better option.
Most, if not all, of the ESAPI developers also subscribe to that
mailing list as well. But it would have the advantage of getting
in front of more ESAPI users so if they every had the same
problem they might be able to find it later by searching the archives.
In fact, I should have CC'd it during my last response. (For that
reason, I'm going to CC: that list now and leave the original part
of this thread rather than trimming it off.)

> thanks again...

NP. Glad it was so easy. I like those kind. :)

> Am 17.03.2012 01:15, schrieb Kevin W. Wall:
>> On Fri, Mar 16, 2012 at 6:17 PM, Jörg Liedl
>> <joerg.liedl at student.htw-berlin.de>  wrote:
>>> Hi ESAPI List,
>>> I have a question....
>>> I use:
>>>        String testEncrypt = ESAPI.encryptor().encrypt("stringToEncode");
>>>        String testDecrypt = ESAPI.encryptor().decrypt(testEncrypt);
>>> to encode and to decode... (esapi ist working, i use it for hashing the
>>> password, and everything works fine, as far as i see..)
>>> but with encode and decode i get this error, i hope somebody can help
>>> me...
>>> thanks!
>>> joerg
>>> javax.servlet.ServletException: Encryption failure: invalid cipher mode (
>>> CBC) for encryption
>>>        javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
>>>  org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
>>>  org.owasp.esapi.errors.EncryptionException: Encryption failure: invalid
>>>  cipher mode ( CBC) for encryption
>>>  org.owasp.esapi.reference.crypto.JavaEncryptor.encrypt(JavaEncryptor.java:390)
>>>  org.owasp.esapi.reference.crypto.JavaEncryptor.encrypt(JavaEncryptor.java:360)
>>>  org.owasp.esapi.reference.crypto.JavaEncryptor.encrypt(JavaEncryptor.java:350)
>> [...big snip of exception stack trace...]
>> Jörg,
>> I'll try to answer your question after you answer my questions:
>> 1) *Exactly* which version of ESAPI are you using?
>> 2) Why are you using the old deprecated methods?
>> 3) Are you using a stock ESAPI.properties file or have you made any
>> changes
>>     to it, specifically, to *any* of the properties starting with
>>     "Encryptor.", other than Encryptor.MasterSalt and Encryptor.MasterKey?
>>     (If you are not sure, "diff" your version from the stock version.)  In
>>     particular, changing
>>         Encryptor.cipher_modes.additional_allowed=CBC
>>     to something like:
>>         Encryptor.cipher_modes.additional_allowed=
>>     or to something other than including CBC would produce *exactly*
>>     the sort of error that you are seeing.
>> 4) Did you remember to generate *new* Encrptor.MasterKey and
>>     Encryptor.MasterSalt properties and paste them into your
>>     ESAPI.properties file or are you possibly using ones that you
>>     previously had?
>> Of these, my biggest concern for you is to stop using the deprecated
>> encrypt() and decrypt() methods as these will certainly disappear 2.1 or
>> 3.0, whichever comes first.
>> As far as the rest of the list is concern, a little feedback is hereby
>> solicited?
>> Assuming that Jörg is using some relatively recent version of ESAPI 2.0,
>> this
>> would be the code fragment generating the exception:
>>  // This way we can prevent modes like OFB and CFB where the IV should
>> never
>>  // be repeated with the same encryption key (at least until we support
>>  // Encryptor.ChooseIVMethod=specified and allow us to specify some
>> mechanism
>>  // to ensure the IV will never be repeated (such as a time stamp or other
>>  // monotonically increasing function).
>>  // DISCUSS: Should we include the permitted cipher modes in the exception
>> msg?
>>  if ( ! CryptoHelper.isAllowedCipherMode(cipherMode) ) {
>>      throw new EncryptionException("Encryption failure: invalid cipher
>> mode ( " + cipherMode + ") for encryption",
>>                  "Encryption failure: Cipher transformation " + xform
>> + " specifies invalid " +
>>                  "cipher mode " + cipherMode);
>>  }
>> This is only reached if you are not using a (so-called by NIST) "combined"
>> cipher mode (e.g., CCM, GCM, etc.) that supports both confidentiality AND
>> authenticity. It relies on checking the ESAPI property
>>     Encryptor.cipher_modes.additional_allowed
>> to see your specified cipher mode is included in the comma-separated list
>> of values. If it isn't, you will get this exception.
>> Well, note the 'DISCUSS' note here. I considered listing the
>> cipher mode to improve the error message. I could just add something
>> that says something the effect of
>>     Permitted cipher modes are:<allowed_cipher_modes_here>
>> by simply placing the value for Encryptor.cipher_modes.additional_allowed
>> here. I think it's perfectly harmless to include this in the logMessage
>> part of the exception message, but if one were so bone-headeds to
>> have it set to something like (oh, I dunno) "ECB", well that just might
>> help an attacker if it were in the userMessage. However, as seen by this
>> specific question that Jörg asks, the developer doesn't always remember
>> to look at the logMessage associated with most ESAPI exceptions.
>> So I was thinking of perhaps changing the userMessage for this exception
>> to something like:
>>  throw new EncryptionException(
>>             // userMessage
>>         "Encryption failure: invalid cipher mode ( " +
>>         cipherMode + ") for encryption; for permitted modes see " +
>>         "the property 'Encryptor.cipher_modes.additional_allowed' in your
>> " +
>>         "ESAPI.properties file.",
>>             // logMessage
>>         "Encryption failure: Cipher transformation " + xform +
>>         " specifies invalid " + "cipher mode " + cipherMode +
>>         ".  Permitted cipher modes are: " +
>>         ESAPI.securityConfiguration().getAdditionalAllowedCipherModes()
>>         );
>> This is fairly easy to do, even if it's not so pretty. The
>>         ESAPI.securityConfiguration().getAdditionalAllowedCipherModes()
>> returns an ArrayList<String>  so this will end up printing out using
>> AbstractCollection<E>.toString() to print it out as a collection. (A
>> little more effort could pretty it up a bit, but why bother as it
>> is only intended for development support?)
>> So, what do all of you think? Would it be a good idea to embellish these
>> exception messages as described? Let me hear your thoughts. If you think
>> it would, I'll create Google issue and assign it to myself.
>> Thanks,
>> -kevin
>> --
>> Blog: http://off-the-wall-security.blogspot.com/
>> "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.
> --
> Jörg Liedl

Blog: http://off-the-wall-security.blogspot.com/
"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

More information about the Esapi-user mailing list