JavaTM Cryptography Extension (JCE) 1.2.1

Frequently Asked Questions


  1. What is new in JCE 1.2.1 compared to JCE 1.2?
  2. Is there an archive of JCE mailing lists?
  3. What are the licensing terms for JCE 1.2.1?
  4. Can I access the JCE 1.2.1 software from outside the U.S. or Canada?
  5. I heard that the US Government has relaxed the export restrictions on encryption products. How does this affect JCE 1.2 and JCE 1.2.1?
  6. Will the source code to JCE 1.2.1 be made available through the Sun Community Source License program?
  7. Can I bundle JCE 1.2.1 with my product and export it?
  8. Does JCE 1.2.1 work with JDK 1.1.x?
  9. Is JCE 1.2.1 written in the JavaTM programming language?
  10. My cipher implementation is not found. Why?
  11. Can I assume that JCE 1.2.1 and J2SDK have been configured properly if MessageDigest.getInstance("MD5") works?
  12. When I use javax.crypto.CipherOutputStream to encrypt data and write it to the underlying output stream, and javax.crypto.CipherInputStream to read the encrypted data from the underlying input stream and decrypt it, there seems to be a problem if the encapsulated Cipher object implements a block cipher w/ padding.

Questions and Answers

  1. Q: What is new in JCE 1.2.1 compared to JCE 1.2?
    A: The primary difference between JCE 1.2 and JCE 1.2.1 is that JCE 1.2.1 is exportable outside the U.S. and Canada, due to mechanisms it implements to ensure that only qualified providers can be plugged into the framework. Qualified providers include those approved for export and those certified for domestic use only. Qualified providers are signed by a trusted entity.

    JCE 1.2.1 providers may also be exportable. Please refer to How to Implement a Provider for JavaTM Cryptography Extension 1.2.1 for more information.

    The JCE 1.2.1 software from Sun Microsystems now has a single distribution for both domestic and global users. The bundled jurisdiction policy files contain no restrictions on cryptographic strengths.

  2. Q: Is there an archive of JCE mailing lists?
    A: There is no JCE-specific mailing list. However, the
    java-security@sun.com alias provides a feedback mechanism for the security components of the Standard Edition Java Platform, including the JCE optional package.

    All emails sent to that alias are archived at: http://archives.java.sun.com/archives/java-security.html.

  3. Q: What are the licensing terms for JCE 1.2.1?
    A: Sun's release of JCE 1.2.1 is a non-commercial reference implementation. The release may be used royalty-free as part of commercial applications. See the
    software license for more information.

  4. Q: Can I access the JCE 1.2.1 software from outside the U.S. or Canada?
    A: Yes. JCE 1.2.1 is exportable, meaning that it can be downloaded from most countries. The exportability is the major new feature in JCE 1.2.1. However, the following countries may not receive ANY US-developed encryption items, including JCE 1.2.1: Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Serbia/Montenegro (Yugoslavia), Sudan, Syria and parties listed on the Denied and Restricted Parties List.

  5. Q: I heard that the US Government has relaxed the export restrictions on encryption products. How does this affect JCE 1.2 and JCE 1.2.1?
    A: There has been some relaxation in the export requirements for encryption products. Go to
    http://www.epic.org/crypto/export_controls/regs_1_00.html for a complete 33-page report on current export requirements. Note also that a vendor's product status is dependent on the type of application they have with the government and at what point the product was in in the government's application process when the new regulations passed. Contrary to some articles in the press, export of encryption items is still a complicated, multi-dimensional issue.

    JCE 1.2 is still not exportable, because export control restrictions by the U.S. Department of Commerce prohibit frameworks for encryption services from being exported unless appropriate mechanisms have been implemented to ensure that only qualified providers can be plugged into the framework. JCE 1.2 does not implement such mechanisms, but JCE 1.2.1 does. This makes JCE 1.2.1 exportable worldwide (except to the embargoed countries listed in the previous answer and those on the Denied and Restricted Parties List).

    JCE 1.2.1 also includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applets/applications in different jurisdiction contexts (locations). The cryptographic restrictions are specified in "jurisdiction policy files" that are downloaded with JCE 1.2.1. Since the US government has relaxed export restrictions on cryptographic strengths, the JCE 1.2.1 software from Sun Microsystems now has a single distribution for both domestic and global users. The bundled jurisdiction policy files contain no restrictions on cryptographic strengths. This is appropriate for most countries. Other framework vendors could create download bundles that include jurisdiction policy files that specify cryptographic restrictions appropriate for countries whose governments mandate restrictions. Users in those countries could download an appropriate bundle, and the JCE framework will enforce the specified restrictions.

  6. Q: Will the source code to JCE 1.2.1 be made available through the Sun Community Source License program?
    A: Due to current government regulations, at this time, Sun will not be able to make the source code available.

  7. Q: Can I bundle JCE 1.2.1 with my product and export it?
    A: Since JCE 1.2.1 has been granted "retail" status, a product which bundles JCE 1.2.1 may be globally distributable. Consult your export control counsel to verify how the export regulations apply to your product.

  8. Q: Does JCE 1.2.1 work with JDK 1.1.x?
    A: No. JCE 1.2.1 is an optional package (formerly known as an "extension") to the Java 2 Platform. JCE 1.2.1 supplements the cryptographic services defined in the Java 2 SDK (J2SDK), Standard Edition, v 1.2.1 (formerly known as JDK 1.2.1). It does not work with any previous releases.

    Furthermore, Java Software does not provide any version of JCE that works with any JDK 1.1.x release.

  9. Q: Is JCE 1.2.1 written in the JavaTM programming language?
    A: Yes, JCE 1.2.1 is written in the JavaTM programming language.

  10. Q: My cipher implementation is not found. I wrote my own provider that subclasses javax.crypto.CipherSpi and supplies its own cipher implementation. However, I cannot get an instance of my cipher using Cipher.getInstance().
    A: In order to achieve exportability, only providers signed by a trusted entity can be plugged into the JCE 1.2.1 framework. Please refer to
    How to Implement a Provider for JavaTM Cryptography Extension 1.2.1 for more information on how to ensure your provider will work with JCE 1.2.1.

  11. Q: Can I assume that JCE 1.2.1 and J2SDK have been configured properly if MessageDigest.getInstance("MD5") works? The following line of code executes just fine:
      MessageDigest dig = 
          MessageDigest.getInstance("MD5");
    
    However, this line:
      KeyGenerator kgen = 
          KeyGenerator.getInstance("DES");
    
    causes the following exception to be raised:
      java.security.NoSuchAlgorithmException: 
        Algorithm DES not available
    

    A: J2SDK comes standard with a cryptographic service provider named "SUN" (which supplies an implementation of the MD5 message digest algorithm), and JCE 1.2.1 comes standard with a different provider named "SunJCE" (which implements a session key generator for DES). While the "SUN" provider is registered automatically, the "SunJCE" provider needs to be registered explicitly.

    Please refer to the installation guide for directions on how to register the "SunJCE" provider. Once you have registered the "SunJCE" provider, the above exception will disappear.

  12. Q: When I use javax.crypto.CipherOutputStream to encrypt data and write it to the underlying output stream, and javax.crypto.CipherInputStream to read the encrypted data from the underlying input stream and decrypt it, there seems to be a problem if the encapsulated Cipher object implements a block cipher w/ padding. CipherInputStream fails to recover the original data written using CipherOutputStream.
    A: Make sure that you call the CipherOutputStream's close method when you are done writing data to the underlying output stream. This will cause any bytes buffered by the encapsulated Cipher object to be padded and written out.

    Only when you call CipherOutputStream.close() will the encryption operation be finalized, i.e., will Cipher.doFinal() be called (on the encapsulated cipher).