-
Q: What is new in JCE 1.2.2 compared to
JCE 1.2.1?
A:
JCE 1.2.2 is primarily a bug-fix release of JCE 1.2.1. Please refer to
Changes
in JCE 1.2.2 for more information.
-
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.2 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.
-
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.
-
Q: What are the licensing terms for JCE 1.2.2?
A: Sun's release of JCE 1.2.2 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.
-
Q: Can I access the JCE 1.2.2 software
from outside the U.S. or Canada?
A: Yes. JCE 1.2.2 is exportable, meaning that it can be downloaded
from most countries. However, the following countries may not receive ANY
US-developed encryption items, including JCE 1.2.2: Afghanistan, Cuba,
Iran, Iraq, Libya, North Korea, Serbia/Montenegro (Yugoslavia), Sudan,
Syria and parties listed on the Denied and Restricted Parties List.
-
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.2?
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 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.2 does. This makes
JCE 1.2.2 exportable worldwide (except to the embargoed countries listed
in the previous answer and those on the Denied and Restricted Parties List).
JCE 1.2.2 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.2. Since the US government has relaxed
export restrictions on cryptographic strengths, the JCE 1.2.2 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.
-
Q: Will the source code to JCE 1.2.2 be made
available through the Sun Community Source License program?
A:
No, the source code will not be made available.
-
Q: Can I bundle JCE 1.2.2 with my product
and export it?
A: Since JCE 1.2.2 has been granted "retail" status, a product
which bundles JCE 1.2.2 may be globally distributable. Consult your export
control counsel to verify how the export regulations apply to your product.
-
Q: Does JCE 1.2.2 work with JDK 1.1.x?
A: No. JCE 1.2.2 is an optional package (formerly known as an
"extension") to the Java 2 Platform. JCE 1.2.2 supplements the cryptographic
services defined in the Java 2 SDK (J2SDK), Standard Edition, v 1.2.1 (formerly
known as JDK 1.2.1) and later versions. It does not work with any previous
releases.
-
Q: Is JCE 1.2.2 written in the JavaTM
programming language?
A: Yes, JCE 1.2.2 is written in the JavaTM
programming language.
-
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.2 framework. Please
refer to
How to Implement a
Provider for JavaTM Cryptography Extension
1.2.2 for more information on how to ensure your provider will work
with JCE 1.2.2.
-
Q: Can I assume that JCE 1.2.2 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.2 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.
-
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).
