Adrian,
The actual stack trace is the following:
java.security.NoSuchAlgorithmException: Cannot find any provider supporting
DES/ECB/NoPadding
at javax.crypto.Cipher.getInstance(DashoA6275)
at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171)
at org.apache.commons.httpclient.auth.NTLM.encrypt(NTLM.java:223)
at
org.apache.commons.httpclient.auth.NTLM.hashPassword(NTLM.java:520)
at
org.apache.commons.httpclient.auth.NTLM.getType3Message(NTLM.java:471)
at
org.apache.commons.httpclient.auth.NTLM.getResponseFor(NTLM.java:157)
at
org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:1
94)
at
org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:2
27)
(...)
I neve used JCE before, so I really don�t know its details. To me, the only
possible explanation is export restrictions. But DES is a weak algorithm and
I didn�t know that there was restrictions upon it.
I tried downloading Cryptix JCE Provider and using it. It didn�t work, even
with JCE unlimited strength jurisdiction policy files.
Cryptix docs says that to use it, we only need to put it in the classpath.
However, I think I should tweak the java.policy file, or use some sort of
static code to initialize the new providers. I�ll search through the JCE
docs...
Andre
-----Mensagem original-----
De: Adrian Sutton [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 21 de julho de 2003 20:59
Para: Commons HttpClient Project
Assunto: Re: RES: NTLM Error
On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira
Aragao wrote:
> Adrian,
>
> By the way, I couldn�t find about JCE anywhere in the httpclient home
> page.
> Analyzing the log I sent before, I found the following:
>
> 2003-07-21 18:41:44,472 [main] DEBUG
> org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider
> (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman,
> HMAC-MD5,
> HMAC-SHA1)
>
> Does it means that httpclient detected JCE correctly??
Hmm, it would seem to have detected it correctly. We're really going
to need the actual error message that coming out of the NTLM class then
and our current exception handling doesn't seem to provide that. I
don't currently have time to do up a test build which prints the
exception but if you wouldn't mind grabbing the sources from CVS and
trying it yourself, I think you should find the details fairly useful.
Essentially, look through org.apache.commons.httpclient.NTLM and make
sure it prints out the stack trace for every exception it catches.
If not, I can take a better look into this tonight when I get home.
It is possible that export policies are biting you here, and it may be
worth doing up a simple test app that creates the NTLM type 3 message
using the NTLM class or better just tries to encrypt something with DES
to see if it works. There are test cases in the source code that will
try to generate a type 3 message and they may be quite informative as
well. I'd actually try running the tests before modifying the
HttpClient code as mentioned above.
> Andre
Regards,
Adrian Sutton.
----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
