Re: javax.crypto

[Marco Trudel <mtrudel at gmx dot ch>]

Casey Marshall wrote:
> Marco Trudel wrote:
> > Hello list
> >
> > I use a --disable-shared GCJ, built two days ago (revision 117030)...
> >
> > What's the state of javax.crypto? Gnu classpath states that they
> > implemented it mostly. But when running a compiled test app (attached),
> > I get:
> >
> > WARNING: Error loading security provider gnu.javax.crypto.jce.GnuCrypto:
> > java.lang.ClassNotFoundException: gnu.javax.crypto.jce.GnuCrypto
> > WARNING: Error loading security provider gnu.javax.crypto.jce.GnuSasl:
> > java.lang.ClassNotFoundException: gnu.javax.crypto.jce.GnuSasl
> > WARNING: Error loading security provider
> > gnu.javax.net.ssl.provider.Jessie: java.lang.ClassNotFoundException:
> > gnu.javax.net.ssl.provider.Jessie
> > WARNING: Error loading security provider
> > gnu.javax.security.auth.callback.GnuCallbacks:
> > java.lang.ClassNotFoundException:
> > gnu.javax.security.auth.callback.GnuCallbacks
>
> You probably get these warnings because of --disable-shared. Security
> providers are loaded dynamically, based on a configuration file, and in
> a statically linked system that might fail (though, I don't know why it
> should; I would assume that those symbols would be linked in).

You're right. I really should have a shared gcj around for testing 
purposes...


> However, even if the dynamic loading fails, we initialize our providers
> with our default set. You can confirm that these providers are loaded by
> calling Security.getProviders, and listing them.

Mohan already pointed out how to solve this for a static gcj (see his 
mail in the thread). In case you're still interested, here the providers:

Withhout Mohans static initializer:

gnu.java.security.provider.Gnu: name=GNU version=1.0

With:
gnu.java.security.provider.Gnu: name=GNU version=1.0
gnu.javax.crypto.jce.GnuCrypto: name=GNU-CRYPTO version=2.1
gnu.javax.crypto.jce.GnuSasl: name=GNU-SASL version=2.1
gnu.javax.net.ssl.provider.Jessie: name=Jessie version=1.0
gnu.javax.security.auth.callback.GnuCallbacks: name=GNU-CALLBACKS 
version=2.1


> > Exception in thread "main" java.security.NoSuchAlgorithmException:
> > PBEWithMD5AndDES
> >    at javax.crypto.SecretKeyFactory.getInstance(bin)
> >    at CryptionUtilities.crypt(bin)
> >    at CryptionUtilities.main(bin)
>
> We don't implement PBEWithMD5AndDES in Classpath or libgcj. So
> regardless of whether or not static linking is causing issues, this
> program will still throw this exception.
>
> (I get the same exception on jamvm, with Classpath HEAD, minus the
> warnings).
>
> > Do I miss some requirements? I didn't find anything on the net...
>
> Do you have a pointer to a description of the PBEWithMD5AndDES
> algorithm? It's probably pretty easy to write, because the building
> blocks are all there.

Actually I was only prototyping to check if things work at all. I had an 
old DES method somewhere and used it... I intend to use AES and updated 
my prototyp :-)


thanks a lot
Marco