Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

[Kevin W. Wall]

Peter Gutmann wrote:
> David Wagner <daw at cs.berkeley.edu> writes:
> 
>> (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)
> 
> The answer to that depends on whether you need to support an existing base of
> crypto software and hardware.  Even though (in this case) it's a new standard,
> it still requires support from the underlying crypto libraries.  If little or
> none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very
> recent versions of OpenSSL do... it's not looking good) then you'd want to
> stick with HMAC-SHA1.
> 
> (Forestalling the inevitable "but developers can implement AES-CMAC themselves 
> from raw AES" that I'm sure someone will follow up with, the target audience 
> for this is web application developers, not cryptographers, so you need to 
> give them something that works as required out of the box).

Peter has hit the proverbial nail right on the head. I apologize if I did
not make this clear in my original post, but but one goal of OWASP ESAPI
is to not require a whole lot of dependencies. In the context of Java crypto,
this means that we *ideally* would like to have no other dependency other than
the SunJCE, that is, the Sun reference implementation for JCE. Recently we
decided to required Java 6, but even with that, our choices for cipher
algorithms, cipher modes, and padding schemes are limited. For SunJCE,
this is what we have available to choose from:

    Supported symmetric cipher algorithms:
        AES, DES, DESede, Blowfish, RC2, ARCFOUR

    Supported cipher modes:
        CBC, CFB, CTR, CTS, ECB, OFB, PCBC

    Supported padding schemes:
        NoPadding, PKCS5Padding ISO10126Padding
        OAEPPadding, OAEPWith<digest>And<mgf>Padding
        PKCS1Padding, SSL3Padding

(Obviously some of these padding schemes such as OAEP are not suitable
with symmetric ciphers. Or at least I don't think they are.)

So given these limited choices, what are the best options to the
questions I posed in my original post yesterday? As Peter mentioned, we
want to give web app developers something that will work out-of-the-box.
For that reason we don't even want to require that developers use some other
JCE provider like Bouncy Castle, Cryptix, IAIK, etc. even though they may
have more suitable cipher modes or padding schemes.

Lastly, I wanted to respond to one other point that David Wagner brought
up in an earlier reply:

> Advice: Provide one mode, and make it secure.  Try to avoid
> configurability, because then someone will choose a poor configuration.

There's a few reasons for supporting different configurations here. One
is the backward compatibility with previous ESAPI versions, and the second
is to support legacy cases. My experience at my day job is that no one
really changes the crypto defaults anyway if you make it easy enough for them
to use. The main exception is if they have to be compatible with something else
such as some 3rd party vendor software that uses a different mode, etc.
What we can try to do is provide adequate warning in documentation or
in logged warnings if one tries to use anything other then the default.

BTW, thanks to all who replied. I've learned quite a bit from all your
responses, but it looks like I have a lot of research to do before I
understand everything that all of you said.

Regards,
-kevin
-- 
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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com