javax.crypto

Wed Sep 20 19:44:00 GMT 2006

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