I have the dubious honor of having written one of the very first implementations of the RSA cryptographic algorithm in Java some years ago, and very badly I wrote it too.

With a 4-bit key it worked great, with an 8-bit key it took about 30 minutes to encrypt or decrypt anything, and after three days of trying with a 16-bit key, we had to use the computer for something else. Just to give you some idea, even back then 128 bits was considered the minimum for secure communications, and each bit doubles the time. Cryptography is not fast; its security is bound up in the complexity of its algorithms. Those who are writing modern cryptography need to be much better mathematicians than I. Of course, Java is not a fast language ­ as Java developers, the price we pay for platform independence and stability is speed ­ so writing cryptography in Java doesn't make a lot of sense on the surface.

On servers it's a relatively simple matter to add another processor, and even today's desktop systems have no problems running (efficiently coded) cryptography routines in Java, but mobile devices have enough trouble just updating the screen and responding to inputs. Getting Java working is hard enough in such constrained environments, but adding cryptography to the Java mix on a mobile device is surely madness!

Mobile Security
Getting decent cryptography onto mobile devices has been an aim for a long time; while SSL (or TLS, as it's now known) provides for most of our security needs on the desktop, the algorithms and processes it uses are often beyond the ability of the devices in our pockets. Mobile telephones, in particular, are changing into mobile payment devices in the first stages of the long-awaited move to an electronic currency. PayBox is already offering a service enabling payment, both on- and offline, via a GSM mobile telephone, while car-parking meters in the north of England can be reset from a mobile phone. Users are realizing that their mobile phone can do a lot more for them, but current systems are clumsy and often expensive to run, not to mention that when I want to buy something from a shop, it's insane that the shopkeeper and I both have to make phone calls to a central server to authorize the payment.

Technologies like Bluetooth are providing a conduit for more direct interaction ­ a mobile wallet in a Bluetooth-equipped mobile telephone could be used to pay for goods in shops, and even automatically authorize payment for transport without user involvement. In this environment, mobile telephones have one great advantage over PDAs: they're always on, ready to respond to incoming requests or scheduled events.

The barriers to such usage, while temporary, are considerable. The cost of an infrastructure to implement such a payment system is massive, but the lack of standardization is the primary problem. Once everyone is using a standard payment system (perhaps a new Bluetooth profile?), we'll see a mass deployment of mobile payment systems; until then they'll be limited to corporate installations and arcologies, but even then only if strong encryption can be deployed on devices like mobile phones and is available to application developers. GSM mobile phones have a Subscriber Identity Module (SIM) that is often capable of dealing with strong cryptography, but it's also under the complete control of the network operator (for sound commercial reasons) and is rarely available to anyone else.

Why Use Java?
Speed is not the only thing that counts against Java when considering cryptography; memory safety is another issue that has never been satisfactorily resolved. Cryptography is generally based around keys, and security is managed by limiting access to certain keys and ensuring those keys are defended against attack. Applications like Pretty Good Privacy (PGP) store the keys, which are encrypted using a passphrase as a key to decode them, on a desktop computer's hard drive; but while the keys are being used they are in memory and could, in theory, be accessed by another application running at the same time, depending on the operating system being used.

In C it's possible to take steps against such theft, but in Java the programmer has almost no control of the memory, and keys held in RAM could conceivably be read by another application. Even worse, if the encryption program is relying on Java garbage collection, there's no telling how long those keys will actually exist in memory; they could even find themselves paged into virtual memory (on the hard drive) where they might hang about for months before that part of the hard drive is used again!

Java implementations of cryptography generally recommend not using virtual memory, and a modern desktop operating system should provide some memory protection to separate processes, but handheld systems rarely have such protection. Even though being paged to a hard drive isn't a problem, having keys hanging about in memory is not an ideal situation.

Working around these problems isn't easy, so there must be a significant advantage to make Java worthwhile, and it is platform independence that provides that advantage. On desktop computers we have to deal with two or three different operating systems. Even on PDAs there are only three or four to worry about, but on mobile telephones things are a lot more complicated. Symbian has taken great strides with EPOC (their OS), but Palm and WinCE are vying for some market share, not to mention the half-a-dozen proprietary operating systems that are still being used. Even code written in ANSI C can't be relied on to work with every mobile phone. Java is rapidly emerging as the true cross-hardware application platform. Many phones don't actually have the capability to install and remove applications, but even those are moving toward being able to execute MIDlets, opening Java to everything but the most basic handsets.

Java cryptography certainly would be useful for limited devices, and the Connected Limited Device Configuration would seem ideal, but getting RSA, or something similar, working at an acceptable speed would be close to impossible...which brings us to NTRU.

A Different Solution
NTRU was started in 1996 to capitalize on the development by the founders of a new encryption algorithm designed to minimize processing requirements and run on limited devices. In the field of cryptography there are many companies offering "secret" algorithms that they claim are breakthroughs. However, we generally take "secret" to mean "untested," as peer review is the only way for an encryption system to be proved secure. It is, of course, impossible to prove that an encryption system is secure; you can only prove that you personally can't break it (which, if you are me, is no great recommendation). When looking at an encryption algorithm it's important to know that reputable people in the field have attacked it and can't break it. NTRU has spent a few years doing that, relying on a patent to protect its IPR and working with the cryptography industry to demonstrate the strength of its algorithm.

Even with a much-improved algorithm, getting something small enough and fast enough for CLDC devices isn't easy. Trying to do it in Java isn't likely to make it any easier. Even NTRU didn't start in Java; it offers implementations in a variety of languages and on some very small devices, including RFID tags and Smart Cards. But as already discussed, it's the mobile phone explosion that presents the most interesting and potentially profitable application of encryption ­ and Java is the only effective way of reaching those platforms.

Having decided to work on a Java implementation of NTRU's algorithm, there's the minor matter of which version of Java to support. The days of just being "Java compatible" are long gone, and now there seems to be almost as many versions of Java as there were programming languages that Java was supposed to replace! Most of the mobile phones support at least the CLDC specification, so that was a logical place to start.

The NTRU algorithm doesn't require floating point mathematics, which helps, and being an encryption library it has no graphical requirements so it should be usable on all versions of Java, once developed for the CLDC. Indeed, the same core encryption and decryption code is used on both the server and client sides (the server is designed to run under J2SE and provides the same cryptographic services as the client).

As the algorithm had already been implemented in several languages, the port of the core code to Java was completed in a few months by a small team of developers, though testing and integration took considerably longer. Embedded developers still have very little choice in terms of working environment, so the Wireless Toolkit from Sun represents state-of-the-art. NTRU uses Visual Café for its server-side development, as this appears to produce faster compiled code, but on the CLDC side, text editors and command-line compilers are the order of the day.

Worse is the lack of debugging or remote testing environments. While desktop objects may contain their own test harnesses or be loaded into test containers, when your whole application is supposed to be under 5KB it's not easy to get testing in there too. In fact, when you're working under such constraints there are good arguments against object-orientation, and the core of NTRU's cryptographic code reflects this philosophy. By explicitly creating a memory context and managing variables within that context, it hopes to avoid the persistence problems inherent in Java applications, and in most cases it should be right. By avoiding object methodologies, NTRU can also avoid dependence on the Java garbage collector, which can be an unreliable beast at the best of times especially on embedded platforms.

NTRU also decided not to support the JCE. The Java Cryptographic Extension is a mechanism that allows suppliers of cryptography to integrate their libraries in a standard way with Java applications. The API is certainly flexible, allowing detailed control of the cryptographic process, but some would claim that flexibility has led to excessive complexity and made the API difficult to use. People who work in cryptography regularly might find the JCE pretty intuitive, but Java programmers just want to be able to encrypt and decrypt without worrying about the messy details. There is the argument that such programming should only ever be done by professionals, but back in the real world we all want a simple API. There's also the issue that the JCE is not supported by the CLDC, and implementing it would have made the NTRU code much bigger.

Getting cryptographic routines into a 5K CLDC­compatible library is very impressive, but it's not going to solve most of the problems with the scenarios discussed at the beginning of this article. The ability to encrypt communications and provide digital signatures (to enable proof-of-identity, essential for any m-commerce system) is only part of the problem; there's still the issue of where and how the keys will be stored. There is no point in providing wonderfully secure communications when the encryption keys have to be downloaded over an insecure link, so keys will have to be stored somewhere on the device and in a secure manner.

Most of the J2ME mobile telephones being launched at the moment have only the ability to run downloaded Java code. MIDP application installation and management is generally kept to a minimum to ensure the simplicity of the user interface, and file management is often nonexistent. MIDP specifies that data can be stored locally, but the developer has no idea where (physically) that data will be stored and so can't rely on it being secure. NTRU is in the process of approaching handset manufacturers about finding some secure space on their handsets for key storage, but again the lack of standardization causes problems. Manufacturers will need a lot of convincing to embed facilities for NTRU in their handsets, especially when NTRU will be collecting a license on every device using its algorithm. Not to mention, once we're talking about putting things into the handsets, we might as well embed some cryptographic hardware.

Doing the encryption in hardware is inherently more secure than leaving it to the software, and this issue is not limited to mobile devices. As the recent releases about Palladium make clear, the only way to secure any system is to embed the cryptography at a hardware level. GSM mobile phones have a cryptographic chip already embedded in the form of a SIM chip, and if we're going to add cryptographic functions, this is the sensible place for them. While the NTRU algorithm may well be a revolution, and getting it working in Java is spectacular, the practicality and usefulness of a layered security model remain to be seen. We'll certainly see the NTRU algorithm in many places, but it's still hard to see Java being one of them.