At long last, a question that I can (almost) answer! ;-) On Tue, Jan 29, 2013 at 9:05 PM, <[email protected]> wrote: > First, are there any documented vulns in java cryptography providers, > such that one would prefer one over another?
I'm not aware of any outstanding vulnerabilities, but there have been a few in the past. Those in open source JCE providers such as Bouncy Castle are easier to find details about as they are a lot more transparent than Sun or (especially) Oracle. As far as it goes, I suppose one could consider the lack of any AE modes in the standard SunJCE a "vulnerability". Bouncy Castle at least supports CCM and GCM. That's one of the shortcomings that I tried to address with OWASP ESAPI 2.0 for Java. And add to that the recent thread about OAEP weakness with RSA, I'd say there are no secure padding schemes for RSA encryption, at least in SunJCE. (I've not checked what Bouncy Castle has to offer.) > Second, is there any significant reason (e.g. usability) to prefer a > different API than the JCA/JCE? None that I'm aware of, but if you are looking for something that is FIPS 140-2 compliant, there are only two JCE compatible libraries that I'm aware of: IBM Java JCE FIPS 140-2 Cryptographic Module (aka, IBMJCEFIPS) http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2005.htm#497 and RSA Security BSafe Crypto-J http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm#1048 so I suppose that could be viewed as a disadvantage. JCA/JCE also really offers very little in the way of key management and PKI support is fairly weak (well, sparse) as well. > In short, if devs ask 'which crypto library should I use in java' is > there any reason to prohibit anything in particular, or recommend > anything in particular? As far as usability, its a every consistent approach... init/update/doFinal that I, at least, find fairly easy and flexible to use as long as you understand basic constructs like cipher modes and padding schemes. But I wouldn't allow non-crypto literate developers to use it or otherwise you end up with everyone using AES in ECB mode with no padding (which is the default if you just use Cipher.getInstance("AES")). [Seen from way too many cases of personal experience, including the ESAPI 1.4 release, which is why I rewrote it.] ESAPI 2.0 is not perfect, but the approach is sound... just provide safe options and make the tweaks available via configuration properties that you can allow your security team to set. If you want more details on it, contact me off-list as I doubt others really care. ESAPI still has a *long* way to go. (But I've really love getting some volunteers! Hint! Hint!) I think the other good crypto API is "KeyCzar" done Ben Laurie and others at Google. If *all* you are looking for is a crypto lib, I'd probably recommend it as ESAPI has way too much baggage (30 or so dependencies). But if you also need lots of other things like XSS protection, etc., then ESAPI is probably worth a look. > I've been digging around this evening and haven't found much, and > I'm sure someone on this list has done this research before. Hope this helps. -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. We *cause* accidents." -- Nathaniel Borenstein _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
