[cryptography] any reason to prefer one java crypto library over another

Kevin W. Wall kevin.w.wall at gmail.com
Tue Jan 29 22:36:26 EST 2013

At long last, a question that I can (almost) answer! ;-)

On Tue, Jan 29, 2013 at 9:05 PM,
<travis+ml-rbcryptography at subspacefield.org> 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)
 RSA Security BSafe Crypto-J

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.

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 cryptography mailing list