On 30/01/13 05:05 AM, travis+ml-rbcryptogra...@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.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
