I am developing a JCE Provider using native OpenSSL.
I used Bouncycastle.org's basic crypto code to generate the
OpenSSLJCEProvider. So this means that only the essential ASN.1 code
from Bouncycastle is in the Provider jar which loads my JNI bridge
native code that links to the OpenSSL libs. The Bouncy code should
require very little maintenance and is much smaller than the BC stuff
presently in Android.
My immediate interest was a faster Message Digest support for SHA-{1,
256, 512}, MD-{4, 5}, and RIPEMD-160. Other digests are easy to add
if OpenSSL is configured to provide them, e.g., MD2 is not configured
by default. This works fine.
I have the code in place for some of the ciphers, symmetric/asymmetric
(including some of the EC in OpenSSL) using OpenSSL's EVP. I am,
presently, doing choice 1) below on a piece-meal basis. But, I would
like a bit of guidance.
Namely:
1) I can select a subset of crypto-support that is considered
desirable from the Java Provider side; or
2) I can, less easily, obtain all of the crypto-support that has
been configured into the OpenSSL libs, then use this to build and
configure the JCE Provider Services.
Choice 1) is far easier and quicker to generate and test. But, choice
2) has the advantage of being as complete as OpenSSL offers but a bit
more time consuming to complete and test. Which would be the most
desirable?
If this project seems to be desirable should I plan for it to be
incorporated into Android's JVM support libs? Or, should I go it
alone to support my client's mobile apps to use their cloud services?
