Cipher pains

[Stefan Schulz]

Somehow, the JCE continues to amaze me. It claims to support the AES
cypher, yet the following code throws a NoSuchAlgoritmException:

import java.security.NoSuchAlgorithmException;

import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;

public class CypherTest {

public static void main(String[] args) throws
NoSuchAlgorithmException, NoSuchPaddingException {
Cipher aes = Cipher.getInstance("AES");
System.out.println(aes);
}
}

Results in:

Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot
find any provider supporting AES
at javax.crypto.Cipher.getInstance(DashoA12275)
at CypherTest.main(CypherTest.java:10)

But wait, there's more. If i explicitly get my Providers, and list their
Services, i can clearly see Cipher.AES begin supported by the SunJCE
Provider. However, if i explicitly try to instantiate it by

public static void main(String[] args)
throws NoSuchAlgorithmException, NoSuchPaddingException {
Provider jce = Security.getProvider("SunJCE");
Cipher aes = Cipher.getInstance("AES", jce);
System.out.println(aes);
}

I get
Exception in thread "main" java.lang.SecurityException: JCE cannot
authenticate the provider SunJCE
at javax.crypto.Cipher.getInstance(DashoA12275) at
CypherTest.main(CypherTest.java:13)
Caused by: java.util.jar.JarException: Class is on the bootclasspath
at javax.crypto.SunJCE_d.a(DashoA12275) at
javax.crypto.SunJCE_b.b(DashoA12275) at
javax.crypto.SunJCE_b.a(DashoA12275) ... 2 more

Can someone shed some light on this?

--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper

[Stefan Schulz]

On Wed, 09 Feb 2005 11:54:34 +0100, Stefan Schulz wrote:

> Can someone shed some light on this?

Things get stranger and stranger... when i try to do the same outside of
Eclipse, it works like a charm!

Now if only i could make sense of this behaviour...

[Roland]

On 9-2-2005 12:31, Stefan Schulz wrote:

> On Wed, 09 Feb 2005 11:54:34 +0100, Stefan Schulz wrote:
>
>
>>Can someone shed some light on this?
>
>
> Things get stranger and stranger... when i try to do the same outside of
> Eclipse, it works like a charm!
>
> Now if only i could make sense of this behaviour...

Interesting. I see the same behavior.

Did some further experimenting (Eclipse 3.0.1).

It seems to be affected by the setting of 'Use system libraries' in
Window -> Preferences -> Java -> Installed JREs -> (select JRE) -> Edit

If 'Use system libraries' is unchecked (off), Eclipse adds the
'-Xbootclasspath' parameter (with all the libs in the list) to the java
executable. [I used sysinternals.com's Process Explorer to reveal the
commandline of the java executable started by Eclipse.]
If it's checked, Eclipse doesn't add -Xbootclasspath, so it allows the
java executable to discover its on boot classpath.

Running the program from commandline causes java also to discover it's
own boot classpath. I didn't try specifying -Xbootclasspath on the
commandline.

Next question then would be, why java cannot find the algorithm when the
bootclasspath has been specified with all libs from the JRE.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \