Hi list...hope there are some Java developers out there and that this is not too off topic for this list's charter.
Does anyone know the *proper* (and portable) way to check if a Java VM is using the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy files (e.g., for JDK 6, see <https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/viewproductdetail-start?productref=jce_policy-6-oth-...@cds-cds_developer>.) I would like something that works with at least Java 5 and later and that does not have any false positives or negatives. I also would _prefer_ some test that does not require locating and parsing the policy files within the JVM's installed JCE local_policy.jar and US_export_policy.jar files as that seems kludgey and might not work with future JDKs. My first thought was just to try a naive dummy encryption of a test string using a 256-bit AES key. However, I realized that this might still succeed without having the JCE Unlimited Strength Jurisdiction Policy files installed if the JCE provider being used implemented some exemption mechanism (i.e., see javax.crypto.ExemptionMechanism) such as key recovery, key weakening, or key escrow. Then I saw that javax.crypto.Cipher class has a getExemptionMechanism() method that returns either an ExemptionMechanism object associated with the Cipher object OR null if there is no exemption mechanism being used. So I figured I could then do the naive encryption of some dummy string using 256-bit AES/CBC/NoPadding and if that succeeded AND cipher.getExemptionMechanism() returned null, THEN I could assume that the JCE Unlimited Strength Jurisdiction Policy files were installed. (When the default "strong" JCE jurisdiction policy files are installed, the max allowed AES key size is 128-bits.) Does that seem like a sound plan or is there more that I need to check? If not, please explain what else I will need to do. Thanks in advance, -kevin wall -- Kevin W. Wall "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
