Cryptography is not about "unbreakable" but more about making it so hard and time consuming that it is practically useless to crack.

However, as an importer you need to worry about any import laws your country may have.

You have to contact a lawyer for that or you can read the CryptoLaw document.

Server S (sender)

1. Generates a symmetric block cipher(e.g. Twofish)
2. Encrypts the XML and lock data with this block cipher
3. Encrypts the block cipher and IV with the public key (X.509 certificate) of the receiver
4. Create a SIG
5. Pack the encrypted XML & lock data, the encrypted block cipher together with the signature and the sender's public key (X.509 certificate) in one string.
6. Sends the string to server R (receiver)

Server R (receiver)

1. Decrypts the block cipher and IV with his private key
2. Verifies the signature
3. Decrypts the XML with the block cipher
4. Verifies the sender's certificate (valid? not expired? not in CRL? signed by trusted party?)

JCE 1.2.2 has a provider-based architecture. Providers signed by a trusted entity can be plugged into the JCE 1.2.2 framework, and new algorithms can be added seamlessly.

JCE 1.2.2 supplements the Java 2 SDK, Standard Edition, v 1.2.x (J2SDK) and v 1.3.x, which already includes interfaces and implementations of message digests and digital signatures. JCE 1.2.2 is provided as an optional package (formerly known as an "extension") to the Java 2 platform

JCE has been integrated into the Java 2 SDK, Standard Edition, v 1.4.

More information at Sun or the JCE API Guide

Other providers include BeeJCE, Cryptix, and the ones on Sun's list (IBM, RSA, etc...)

The Java Virtual Machine uses a garbage collector (GC) to cleanup memory. In Java we don't have functions to clear the memory. In fact, it is possible that the GC is not called after an operation and that some (sensitive) information stays in memory. So we have to cleanup our "mess" by ourselves.

In Java, Strings are immutable, they can't be changed after they were set. Even if we set the string to null and the GC is called it is not sure that this information is cleared from the memory. With StringBuffers or character arrays we can resize and reset data byte-per-byte. This is what I did, cleanup the StringBuffers after usage, so we are sure that sensitive information such as passwords are stored in memory only during the time needed (as less as possible).

...password="<%= new StringBuffer("mypassword")%>"...

instead of

...password="mypassword"...

If you want to use variables:

<%@ taglib prefix="jce" uri="http://jcetaglib.sourceforge.net"%>
<%@ page import="net.sourceforge.jcetaglib.*"%>

<%
	StringBuffer text = new StringBuffer("Text to encrypt");
	StringBuffer pwd  = new StringBuffer("mypassword");
%>

<jce:encrypt 
	action="encrypt"						
	var="ciphertext"					
	value="<%= text %>"
	algorithm="AES"			
	keyfile="c:/temp/aes_256.key"
	passphrase="<%= pwd %>"/>		 
	
<%-- Cleanup --%>
<%
	CryptTool.blank(text);
	CryptTool.blank(pwd);
	text = null;
	pwd = null;
%>

Encrypted text: <%= pageContext.getAttribute("ciphertext", PageContext.PAGE_SCOPE) %>

Protect your hardware

The security of your operating system is also important. For example you could write an application that uploads files with a browser and encrypt them for secure storage. Most likely you will delete the original file afterwards, but when you delete a file information could still be left on the file system. To avoid this you could use a wipe utility called from your JSP instead of deleting the file. BCWipe is very good for this purpose and available for Unix and Windows (http://www.jetico.com)

When you are running on a Windows platform the swap file is also important to take care of. The JVM could leak some sensitive information to it. BestCrypt (http://www.jetico.com) is able to encrypt your swapfile and has an anti-keylogger mechanism.

Use a truly random seed (available starting from beta 6) when creating your keys and last but not least, choose your passwords wisely!