Java bindings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Java bindings

Chris Gray-4
Hello all,

I'm looking for ways to use OpenSLL from Java on an embedded platform (J2ME
CDC), in order to be able to take advantage of the hardware crypto
acceleration which is available on that platform. Does anyone out there have
experience of this? Google comes up with a number of projects:
 - JavaSSL: link (from http://www.openssl.org/related/apps.html) is broken.
 - ITISSL: server http://sponsor.iti.informatik.tu-darmstadt.de/itissl/ is not
reachable.
 - SSLava  (from Phaos): but does this useOpenSSL? Looks like not.
 - PureTLS + GoNative: looks hopeful, but is it maintained? The web page
mentions a serious problem with SHA-1 which "will be fixed in the next
version" ...

BTW what is GSS-API (RFC 2853), which also turned up in my searches? I know it
stands for Generic Security Service, but where does it fit into the puzzle?

TIA,

Chris

--
Chris Gray        /k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
[hidden email]                         +32 3 216 0369

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Java bindings

Bear Giles
I looked at this a while back, ultimately decided to go with a
pure java implementation (BouncyCastle, iirc) since it was
sufficient for my needs.

Anyway, you can use JNI to create a binding between the OpenSSL
library and Java.  This is a C layer and your main hassle will be
ensuring that you have the memory management down cold.

On the java side, you should find a copy of Java Security
(O'Reilly) or comparable text and implement the full SPI so you
can use the standard java classes.  (You'll need to list yourself
as a crypto service provider in the runtime configuration file --
see the book for details.)  In J2SE you'll want to look at the
javax.crypto.*Spi classes, I'm not sure if they're the same in J2ME.

You could implement your own interface, of course, but that would
prevent you from using third party libraries written to the
standard interfaces.  I think it's also much more risky from a
project management perspective - how stable will your interface
be, how will changes propagate through the rest of the software,
how long will it take new staff to come up to speed, etc.

Bear

Chris Gray wrote:

> Hello all,
>
> I'm looking for ways to use OpenSLL from Java on an embedded platform (J2ME
> CDC), in order to be able to take advantage of the hardware crypto
> acceleration which is available on that platform. Does anyone out there have
> experience of this? Google comes up with a number of projects:
>  - JavaSSL: link (from http://www.openssl.org/related/apps.html) is broken.
>  - ITISSL: server http://sponsor.iti.informatik.tu-darmstadt.de/itissl/ is not
> reachable.
>  - SSLava  (from Phaos): but does this useOpenSSL? Looks like not.
>  - PureTLS + GoNative: looks hopeful, but is it maintained? The web page
> mentions a serious problem with SHA-1 which "will be fixed in the next
> version" ...
>
> BTW what is GSS-API (RFC 2853), which also turned up in my searches? I know it
> stands for Generic Security Service, but where does it fit into the puzzle?
>
> TIA,
>
> Chris
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Java bindings

Chris Gray-4
On Sunday 25 September 2005 16:19, Bear Giles wrote:
> I looked at this a while back, ultimately decided to go with a
> pure java implementation (BouncyCastle, iirc) since it was
> sufficient for my needs.

Hi Bear, thanks for the reply.

BouncyCastle is what we're doing now. I was looking for something
OpenSSL-based because we are working with some hardware which has crypto
features, and there is a port of OpenSSL which takes advantage of these.
Another reason to prefer a largely-native implementation is that we currently
don't have JIT on this hardware.

In the meantime I've heard that someone has hacked BouncyCastle to add native
access to these features, so it looks like that's the way we'll be going.

> Anyway, you can use JNI to create a binding between the OpenSSL
> library and Java.  This is a C layer and your main hassle will be
> ensuring that you have the memory management down cold.
>
> On the java side, you should find a copy of Java Security
> (O'Reilly) or comparable text and implement the full SPI so you
> can use the standard java classes.  (You'll need to list yourself
> as a crypto service provider in the runtime configuration file --
> see the book for details.)  In J2SE you'll want to look at the
> javax.crypto.*Spi classes, I'm not sure if they're the same in J2ME.

Yes, indeed. However that's actually quite a lot of work, and I don't think
it's all that easy: it's not just a matter of writing JNI "wrappers". That's
why I was looking at picking up from an existing project.

> You could implement your own interface, of course, but that would
> prevent you from using third party libraries written to the
> standard interfaces.  I think it's also much more risky from a
> project management perspective - how stable will your interface
> be, how will changes propagate through the rest of the software,
> how long will it take new staff to come up to speed, etc.

Yes, this would be a substantial burden, and not the way I would want to go.
If there were a non-standard set of bindings already exisitng with some kind
of user base then that might be acceptable, but creating a new one would be a
Bad Thing.

Thanks,

Chris

--
Chris Gray        /k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
[hidden email]                         +32 3 216 0369

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]