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

ianG iang at iang.org
Wed Jan 30 04:01:24 EST 2013


On 30/01/13 05:05 AM, 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've never heard of any.  The major vulnerability in my experience is 
the system, leading to loss of operation, wheel-spinning, costs.  The 
effect on the business is generally more traumatic, and vulnerabilities 
never seem to surface above that noise level.

> Second, is there any significant reason (e.g. usability) to prefer a
> different API than the JCA/JCE?


Don't get me started.  Short story, don't ever use the JCA/JCE if you 
can avoid it.  Even if you can't avoid it, think carefully.  Change 
business, leave the country first, join a monastery first.

> 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?


Do it yourself.

> 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.



Just yesterday I finished a 17 day effort to rip out all JCE/JCA and 
provider code out of my system, and replace it with snippets of raw 
algorithm code (Taken from bouncy castle and cryptix).  Not only am I 
biased, I'm also not thinking straight as I've not had a break...



That grumbled, here are some thoughts.

The problems that exist with JCE crypto are many.  Firstly, one faces a 
repetitive failure mode which is that every new platform has to be 
configured with permission to use strong crypto, otherwise it throws an 
infamous but obscure Dasho exception[0].  If your application involves 
userland, you're starting to sink right there [1].

Then, every provider is subtly different, documention is not wonderful, 
and you are looking at the problem through multiple layers of 
obfuscation.  Just one issue.  You have to specify modes through a text 
string:  Is it "AES/CBC/HMAC" or is it "AES128/CBC/HMAC/SHA1" ...  So 
you can spend ages trying to figure out some subtle thing, only to have 
to resort to the source.  Or, you switch provider and it all stops 
working.  Or, or, or...



My own personal disaster was triggered by switching from mac to android 
- the crusty old Cryptix code [2] that I used was "not allowed" by 
Android because it replaces some of the Sun stuff (javax).  Literally 
Cryptix replaced the JCE which is allowed in other platforms but blows 
up in Android.  Just as confusing, Android comes with built in 
BouncyCastle but it turns out to be "cut down BC" and of course doesn't 
come with the stuff I want.  So one can then install SpongyCastle which 
is a renamed BC (which also isn't allowed in various places).

Which meant I was now dealing with multiple providers depending on which 
platform:  Cryptix for laptop, SC for android, BC for server...

JCE isn't simple lockin, it's triple lockin.  As well as being locked in 
to the basic JCE style of things, you're locked into the USG agenda (all 
your security base belong to NIST).  Elvis left that building a long 
time ago.  Also, you're locked into the provider, which is trying 
desperately to provide the basics to compete with other suppliers, while 
providing the good stuff that people really need.  Your provider is 
likewise locked in to Sun, as it needs to get its signing cert signed by 
Sun/Oracle otherwise it cannot publish patches [3].

Can you feel the dumbing down effect here already?

E.g., I used a LOT of OpenPGP.  In switching to BouncyCastle, I had to 
not only rewrite every line of OpenPGP userland code, I was also facing 
compatibility issues, completeness issues, style issues and a basic 
paucity of doco (on both providers).  Oh, and bugs.  These providers 
aren't bug free.  With all the Cryptix source in front of me I failed to 
debug a basic standard mode in OpenPGP;  with all the source of BC in 
front of me, I failed to understand their OpenPGP model so as to start 
rewriting.



I started writing a meta-provider, one that would switch between the 
providers depending on which complicated platform set it could detect.



End result - I was faced with a complete rewrite of everything.  Bullet 
bitten, 17 days later I got the client up so that the developers could 
get back into android hacking.  (Haven't finished yet, gotta do more 
userland clients & server rewrites.)

But, looking back:  I now have less code to deal with.  I have my own 
code all they way through.  It feels right, so much brighter!  Rewriting 
the basic key set was simpler than dealing with Certificates or OpenPGP, 
either, let alone the complications of converting one provider key to 
another.  Having to add all the crypto modes was necessary anyway 
because as we are discovering [4], the various PKCS1, OAEP, CBC modes 
are such a small part of the overall crypto transaction code that they 
get in the way as much as they help.

So my message is:  DIY crypto rocks [5].  JCE/provider crypto is so not 
the answer I've forgotten what the question is.  With Java in 
particular, life is very bipolar, there is such a gulf between the 
bureaucracy of the Oracle and the anarchy of DIY that neither side 
recognises the other.




iang


[0] I kid not - Sun JCE deliberately obfuscates itself to slow down 
replacement, and deliberately throws an obfuscated exception when the 
permission isn't configured.  It's called the Dasho obfuscator, further 
indicating that in the minds of the security team, this planet revolves 
around Sun.

[1] If your application involves a lot of crypto, you might want to also 
ask whether Java is the right language for you.  No other language is 
embuggered this way, AFAIK.

[2] my old Cryptix team pioneered Java crypto and PGP in the late 90s. 
Sun followed and clamped down on free libraries like ours by inventing 
the JCE permissions framework.

[3] Unfortunately Cryptix team did not see the lockin coming.  We got a 
Sun certificate, but it expired.  We are no longer permitted to sign 
under light of day.  But we can backdate to nighttime ...

[4] This is what my OAEP question was about - I had to write a signing 
mode and an encryption mode.

[5] I had a similar failure last year with Perl crypto.  I spent around 
2 weeks trying to get Perl maths libraries going which Perl crypto is 
layered on going.  In the end, I gave up and spent a month rewriting all 
the perl in Java, so I could use our java crypto.



More information about the cryptography mailing list