Peter Gutmann wrote: > David Wagner <d...@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 majord...@metzdowd.com