Encryption Tools

Encryption software, whether for XML or otherwise , is restricted by law in many jurisdictions, including the United States. Consequently, encryption software is less available than it should be, and it is often excessively difficult to install or configure. Vendors have to jump through hoops to be allowed to publish, sell, and export their products. The exact number of hoops varies a lot from one jurisdiction to the next . Thus, unfortunately , XML encryption tools and libraries are less advanced than they otherwise would be.

Almost all implementations of XML encryption at the current time seem to be Java class libraries, although that's likely to change in the future. The only non-Java library I've found so far is Aleksey Sanin's XMLSec (http://www.aleksey.com/xmlsec), an open source implementation of XML Encryption for C and C++ that sits on top of the Gnome project's libxml and libxslt .

Moving into the Java realm, there are a lot more choices. Baltimore Technologies' KeyTools XML (http://www. baltimore .com/keytools/xml/index.asp) is a commercial offering written in Java that supports both XML encryption and digital signatures on top of the Java Cryptography Extension (JCE). Phaos has released a commercial XML Security Suite (http:// phaos .com/products/category/xml.html) for Java that also supports encryption and digital signatures.

Possibly the most advanced open source offering at the time of this writing is XML-Security (http://xml.apache.org/security/) from the Apache XML Project. This is the same library discussed in Item 48 for producing digital signatures. It is a Java class library that runs on top of Java 1.3.1 and later. It relies on Sun's Java Cryptography Extension to perform the necessary math. The preferred implementation of this API is from the Legion of the Bouncy Castle, which, being based in Australia, doesn't have to submit to U.S. export laws. The Apache XML project can't legally ship the Bouncy Castle JCE with its software, but the Ant build file will download it for you automatically.

IBM's XSS4J also implements various XML encryption algorithms and has a slightly better user interface than XML-Security (that is, it has a user interface). It was used to encrypt the examples shown in this chapter. XSS4J prefers different implementations of the JCE. It can run with Sun's own JCE, but it wants the IBM (http://www7b.boulder.ibm.com/wsdd/wspvtdevkit- info .html) or IAIK (http://jce.iaik.tugraz.at/products/01_jce/) implementations, especially if you want to use RSA encryption or key exchange.

The complexity of the JCE has made most implementations noninteroperable at the API level. However, at the XML document level, matters are much better. Encrypted XML produced by one tool can be read by different tools, provided they support the same algorithms. If you stick to the required algorithms (basically AES and Triple DES for encryption, RSA for key exchange, SHA-1 for message digest, and Base64 for encoding), your documents should be able to be easily encrypted and decrypted by anyone who knows the right key.