no DES provider in java 1.5

[Andrey Kuznetsov]

I used password encription with java 1.4.2_06.

Now with 1.5 I getting following error:

java.security.NoSuchAlgorithmException: Cannot find any provider supporting
DES
at javax.crypto.Cipher.getInstance(DashoA12275)

any clues?


Andrey

 

[Andrey Kuznetsov]

I used password encription with java 1.4.2_06.

Now with 1.5 I getting following error:

java.security.NoSuchAlgorithmException: Cannot find any provider
supporting DES
at javax.crypto.Cipher.getInstance(DashoA12275)

hmm, it seems to be rather problem of jpackit.
it works within IDE and fails when run from jar, regardless java version.

 

[Roedy Green]

java.security.NoSuchAlgorithmException: Cannot find any provider supporting
DES
at javax.crypto.Cipher.getInstance(DashoA12275)

American export law says only 64-bit DES. You have to enable strong
encryption.

Default is 56 bits.

getInstance take a transform e.g. "DES/CBC/PKCS5Padding"

I presume you fed it just plain "DES".

 

[Roedy Green]

hmm, it seems to be rather problem of jpackit.
it works within IDE and fails when run from jar, regardless java version.

Perhaps this little program will help you diagnose the problem.

/**
* Test JCE, find providers and algorithms supported.
*/
package com.mindprod.example;

import static java.lang.System.out;
import java.security.Provider;
import java.security.Security;

/**
* Test JCE, find providers and algorithms supported.
* <p/>
* composed with IntelliJ IDEA.
*
* @author Roedy Green, Canadian Mind Products.
* @version 1.0, 2006-03-15
*/
public final class TestJCE {

/**
* Prepare a list of providers and services.
* @param args not used
*/
public static void main( String[] args )
{
// heading
out.println( "Provider: type.algorithm -> className"
+ "\n aliases:"
+ "\n attributes:\n" );

// discover providers
Provider[] providers = Security.getProviders();
for ( Provider provider : providers )
{
// discover services of each provider
out.println( "<><><>" + provider + "<><><>\n" );
for ( Provider.Service service : provider.getServices() )
{
out.println( service );
}
out.println();
}
}
}

 

[EJP]

American export law says only 64-bit DES. You have to enable strong
encryption.

Default is 56 bits.

This information is many years out of date.

Since 2000, 'Any crypto of any key length can be exported [from the USA]
under a license exception, after a technical review, to non-government
end users in any country except the seven "terrorist countries". Exports
to governments can be approved under a license.'

Since 2002, 'Mass-market crypto with key length exceeding 64 bits can
now be exported after a 30-day review by the Bureau of Industry and
Security.'

See http://en.wikipedia.org/wiki/Export_of_cryptography and
http://rechten.uvt.nl/koops/cryptolaw/.

 

[Tony Morris]

Regardless of what silliness the US establishment dabbles in and
subsequently embarasses itself with, both Sun and IBM still ship with JCE
restrictions.

Until recently, I supported an application that is shipped with the IBM SDK
and required no restrictions on the IBM JCE Provider - do you know how many
times I have asked the question, "have you installed the Unrestricted JCE
Policy Files?" - more than 7.

--
Tony Morris
http://tmorris.net/

American export law says only 64-bit DES. You have to enable strong
encryption.

Default is 56 bits.

This information is many years out of date.

Since 2000, 'Any crypto of any key length can be exported [from the USA]
under a license exception, after a technical review, to non-government end
users in any country except the seven "terrorist countries". Exports to
governments can be approved under a license.'

Since 2002, 'Mass-market crypto with key length exceeding 64 bits can now
be exported after a 30-day review by the Bureau of Industry and Security.'

See http://en.wikipedia.org/wiki/Export_of_cryptography and
http://rechten.uvt.nl/koops/cryptolaw/.

 

[EJP]

Regardless of what silliness the US establishment dabbles in and
subsequently embarasses itself with, both Sun and IBM still ship with JCE
restrictions.

Agreed, but these are import restrictions, not US govt export restrictions.

 

[Roedy Green]

This information is many years out of date.

Since 2000, 'Any crypto of any key length can be exported [from the USA]
under a license exception, after a technical review, to non-government
end users in any country except the seven "terrorist countries". Exports
to governments can be approved under a license.'

That is assumption 1.6 Java is working under. Sun can't very well
handle special exemptions, and I can hardly imagine anyone without a
serious masochistic streak applying for one.

Heavens, a lady got arrested by the homeland goons for paying off her
credit card. That was considered suspiciously unAmerican.

The practical solution is to leave the paranoiod feds lie and get your
software from Australia. see http://mindprod.com/jgloss/jce.html

 

[EJP]

That is assumption 1.6 Java is working under. Sun can't very well
handle special exemptions, and I can hardly imagine anyone without a
serious masochistic streak applying for one.

Hang on, it is Sun doing the exporting ... and Sun who have the export
licence ... and Sun who have built in the unlimited strength
jurisdiction mechanism. There are further steps you can take along this
path, but today you can ship this:

Algorithm Maximum Key Size

DES 64
DESede *
RC2 128
RC4 128
RC5 128
RSA 2048
* (all others) 128

and if you download the unlimited strength policy all restrictions are
off. See http://java.sun.com/products/jce/javase.html#UnlimitedDownload.

There are still restrictions in Sun's JCE *implementation* but use another!