0

Recently I ran into JDK installs from Oracle which had JCE files such as local_policy.jar present in the jre/lib/security directory but those files were dummies and did not truly enable Unlimited Strength encryption. After replacing them with downloads from Oracle, things went much smoother.

Now I'm thinking that there should be an easy way to sanity-test a system and prevent confusion like this. So, I'm wondering:

Which keytool operation could I run that would only succeed if the appropriate JCE jars were installed and in use?

That way, when it fails I know that local_policy.jar is either not available or there is a useless dummy file in place which should be swapped out with the real one.

pulkitsinghal
  • 3,855
  • 13
  • 45
  • 84
  • don't know how to do it with keytool, but you can create a 1 line java program to do it http://stackoverflow.com/questions/7953567/checking-if-unlimited-cryptography-is-available – jtahlborn Mar 05 '13 at 18:18
  • Hmm gets false when the local_policy.jar is present and when it isn't ... this is why I don't want to roll my own solution, its me who could be setting it up wrong. I want to stick to using keytool to figure this out, its present everywhere and no need to starting writing one liners like you suggested: https://gist.github.com/pulkitsinghal/5092928 – pulkitsinghal Mar 05 '13 at 18:39
  • the presence or absence of the local_policy.jar is meaningless, it's the _contents_ of the jar which mean something. that jar is included in the default java install. – jtahlborn Mar 05 '13 at 19:30
  • And what are those contents so that I may confirm? As an aside: One of the tests on that link you quoted above says yes JCE is present and another says no its not ... seems unreliable. – pulkitsinghal Mar 05 '13 at 20:20
  • 1
    i was referring to the max key length test, which (in my testing) is a reliable test of whether unlimited strength cryptography is supported. i assume that is what you are testing for right? you do realize that the JCE is _always_ present, it's just a matter of strength supported. – jtahlborn Mar 05 '13 at 20:26
  • Why don't you point out which test exactly from the SO link you cited? – pulkitsinghal Mar 05 '13 at 23:40
  • it's the one you used in your github gist. – jtahlborn Mar 06 '13 at 02:02
  • Ok well that test can't be right, it always returns false. – pulkitsinghal Mar 06 '13 at 13:32
  • what, specifically, are you testing (the test is right, we use it in our product)? – jtahlborn Mar 06 '13 at 15:00
  • I voted up the JCE is always present comment, I do get that. What I'm testing for: Is unlimited strength supported by the java jdk/jre present on the system or not? The test in the gist link always returns false regardless of the unlimited strength policy jars being present or absent. That bothers me because one state of the JVM should return true and the other should return false. – pulkitsinghal Mar 06 '13 at 15:27
  • as i already said, it's _not_ the presence or absence of the jars that matters. in fact, removing the jars may make it work. you need to test with the _original_ jars installed with the jre/jdk. those jars are _present_ in the original install, but have _different_ contents than the unlimited versions. – jtahlborn Mar 06 '13 at 16:48
  • There's a communication gap on my end so help me understand: How do I make sure to `test with the original jars installed with the jre/jdk`? Because I was under the impression that I am already doing that by NOT dropping in unlimited strength policy jars explicitly. – pulkitsinghal Mar 07 '13 at 17:54

1 Answers1

0

As already mentioned in my various comments, you can use the getMaxAllowedKeyLength() test to determine if a jdk/jre supports unlimited strength cryptography (in my tests i've used the "AES" cipher, but "RC5" should work as well). when testing this functionality, you need to have the right jars in place (the contents of the jars being the important bits).

from my local box, a jdk with limited strength cryptography has a local_policy.jar file with the contents:

// Some countries have import limits on crypto strength. This policy file
// is worldwide importable.

grant {
    permission javax.crypto.CryptoPermission "DES", 64;
    permission javax.crypto.CryptoPermission "DESede", *;
    permission javax.crypto.CryptoPermission "RC2", 128, 
                                     "javax.crypto.spec.RC2ParameterSpec", 128;
    permission javax.crypto.CryptoPermission "RC4", 128;
    permission javax.crypto.CryptoPermission "RC5", 128, 
          "javax.crypto.spec.RC5ParameterSpec", *, 12, *;
    permission javax.crypto.CryptoPermission "RSA", *;
    permission javax.crypto.CryptoPermission *, 128;
};

whereas a jdk with unlimited strength has the contents:

// Country-specific policy file for countries with no limits on crypto strength.
grant {
    // There is no restriction to any algorithms.
    permission javax.crypto.CryptoAllPermission; 
};

(note that the US_export_policy.jar is the same in both cases).

jtahlborn
  • 52,909
  • 5
  • 76
  • 118