Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

Ian G iang at
Fri Sep 18 08:36:32 EDT 2009

On 17/09/2009 21:42, David Wagner wrote:
> Kevin W. Wall wrote:
>> So given these limited choices, what are the best options to the
>> questions I posed in my original post yesterday?
> Given these choices, I'd suggest that you first encrypt with AES-CBC mode.
> Then apply a message authentication code (MAC) to the whole ciphertext
> (including the IV).  You then send the ciphertext followed the MAC digest.
> SHA1-HMAC would be a reasonable choice of algorithm for message
> authentication.

I have to add vote+1 on this selection.  For various reasons, today's 
safe choice seems to be:

   * CBC
   * AES-128
   * HMAC-SHA-1 on the outside of the ciphertext

What is left is padding so that the message is clearly deliminated.  I 
suggest you treat this as a software engineering thing, not a crypto 
thing, and make sure that you have a length in your packet layout so 
that it is totally clear what is the packet and what is not.

If you want to see such a design exercise, following Dave's 
prescription, have a look at SDP1 which Zooko and I did a few years back.

It's a straight forward secret-key encrypted packet layout.  It has one 
novelty in it, which is how it solves the padding / IV issues.  Other 
than that it should be boring.


PS: you are on the right track in trying to avoid any sensitivity to 
JCE.  As long as you can design your layout without any dependency on 
JCE it should work.  JCE is basically a slock design that was put in 
place for market- and crypto-control reasons, it has no place in 
software engineering.  I speak from experience, I managed the Cryptix 
project, which was the first Java crypto engine.

PPS: you haven't said enough about the application (or I missed it) to 
be able to comment on keys.  Generally, try to separate the protocol 
around the key:  every good protocol divides into two parts, the first 
of which says to the second, "trust this key completely".  Software 
engineering ...

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list