The Native interface is part of the "alternate device" feature in Crypto-J, which makes it possible to build applications using any of the following:

• Pure Java code
• Crypto-J, in combination with RSA BSAFE Crypto-C, which is Native code written in C
• Crypto-J, in combination with a third-party hardware device

For the examples in this section, "Java" refers to Crypto-J in pure Java, "Native" refers to Crypto-J with the Native Crypto-C code, and "Acme" refers to a fictional company that manufactures a hardware device.

The advantages of this system include the following:

• You have more flexibility in defining new algorithms.
• You can run the same Java program with great efficiency on a given system.
• You can realize Java's promise: Write once, run anywhere.

Crypto-J provides Native capabilities for Win32, Solaris, and AIX platforms.

Native Interface Calls

It is easy to use different devices - every algorithm factory method, called getInstance, takes an argument that specifies the device type. The following example shows how to specify the device type:

JSAFE_SymmetricCipher.getInstance ("RC2-128/CBC/PKCS5Padding", "Native");

This statement obtains a symmetric cipher object of type RC2 (at 128 effective key bits), with CBC feedback and PKCS5Padding on the Native device. However, using a device in this manner may not provide you with all the possible benefits. For example, if this program runs on a machine that does not contain Native libraries, Crypto-J throws an exception. Or, if the Acme device is available and can use the RC2 cipher, the object that is built will not be able to take advantage of it.

The following example shows an alternate way to specify the device. If the program cannot find the Native library, it will try the Acme library, and finally resort to the Java library.

JSAFE_SymmetricCipher.getInstance ("RC2/CBC/PKCS5Padding", "Native/Acme/Java");

If you want to know which device actually built the object, call the getDevice method.

Java-Specific Calls

Certain Java-specific calls do not work on other devices. For example, cloning will not work with Native libraries. You should thoroughly test a program with all the specified devices before releasing it to the public.

Some devices, including the Native device, cannot build all the specified algorithms. Instead, objects from the other devices are used. In the first example in , the Native device can use the RC2 cipher, but it cannot perform CBC or PKCS5Padding. (RSA BSAFE Crypto-C can use the RC2 cipher with CBC and PKCS5Padding. However, Crypto-J, for algorithm flexibility reasons, wants the device to perform each component separately. Crypto-C cannot perform CBC or PKCS5Padding separately.) However, the feedback and padding portions of the transformation are not as computationally intensive as the RC2 algorithm, so there is very little degradation of performance when you use Java code to perform the CBC and PKCS5Padding portions.

A device may always choose to use Java to perform subsidiary functions, or it may choose to select its replacement options from the device list. The following example illustrates the method you can call to determine which device performs a particular component of the transformation:

String[] getDeviceList();

The elements of the returned array correspond, in order, to the algorithms you specified in the first argument to getInstance. For example, assume that Native can create an RC2 (but not a CBC or PKCS5Padding) object, Acme can create a CBC (but not a PKCS5Padding) object, and Java can create a PKCS5Padding object.

The example below shows that if you call the following:

JSAFE_SymmetricCipher symCipher = JSAFE_SymmetricCipher.getInstance ("RC2/CBC/PKCS5Padding", "Native/Acme/Java"); String[] devices = symCipher.getDeviceList();

the return value, devices, is as follows:

Note: Crypto-C is written in C and does not have garbage collection, so data obfuscation is not necessary for Crypto-C.