| README or Readme Src or Readme Bin Frequently Asked Questions API index Documentation Java Cryptography Extension Specification Utility scripts Copyright and License | Description and Information | Installation | "Regulations" and Patents | Implementation Choices | Compatibility Issues | Working with the Team | Strength, Reliability, Etc. | Performance | Known Bugs | Copyright and License | | Cryptix Development Team

Cryptix TM
Frequently Asked Questions

$Revision: 1.45 $
$Date: 1999/07/31 20:35:56 $

The latest revision of this FAQ is available on a mirrored server near you. It will also be available in the next download.

Table of Contents

- Description and Information

- Introduction
- Where to get Cryptix
- Mailing List
- Business Model
- Support

- "Regulations" and Patents

- EAR/ITAR export regulations
- Can Cryptix be exported from the US?
- Can I export my application using algorithms taken from Cryptix?
- RSAref code
- RSA Patent
- IDEA Patent
- Is it legal for me to use your library?

- Installation

- Documentation
- Compiling the Source Release
- Installing Cryptix as a Static Provider
- Installing Cryptix Dynamically in an application

- Implementation Choices

- Y2K compliance
- Gathering Random Numbers in Java
- History of Cryptix-Java Releases
- Java Serializable Interface
- Applets
- Use of Native Code
- The Java Namespace
- JavaSoft's BigInteger

- Compatibility Issues

- Platform support
- Compatibility with Cryptix 2.2
- The International Java Cryptography Extension

- Strength, Reliability, Etc.

- How strong is it?
- How Can I Be Sure?
- The Advantage of Source Availability
- Which Secret Key Algorithm should I use?
- Working Practice for Broken Algorithms

- Performance

- Hashes
- Block Ciphers
- Public Key Algorithms
- In Search of Faster Encryption

- Known Features

- Using Cryptix with non-writeable Java
- RSA doesn't work
- SHA gives unexpected results

- Known Bugs - Java

- Dynamically added providers might be uninstalled unexpectedly (V3)
- Ciphers with a variable block size can cause an ArrayOutOfBoundsException when used in a mode other than ECB (V3)
- Comments about overlapping arrays in some algorithm classes are inconsistent with the implementation (V3)
- 'finalbuild' compilation script doesn't work (V3)
- ElGamal encryption doesn't work (V3)

- Copyright and License

- Ownership
- Comments on Ownership
- The Cryptix License
- Trademarks

Return to the Cryptix README. Headings below return to the above table of contents.

## Description and Information

### Introduction

The Cryptix libraries contain a suite of cryptographic classes. There is an implementation for each of Java and Perl; this FAQ mainly concentrates on the Java version.

Some of the classes have optional native code for performance reasons. This code has been tested on Windows 95 and Windows NT (Intel x86). Previous versions have been tested on Solaris (SPARC), Linux (Intel x86) and IRIX (MIPS). Both source and binaries are available for various platforms (also see the section, "Use of Native Code.")

### Where to get Cryptix

To download source or binaries, start at the Cryptix Mirror Index. We are actively looking for more mirror sites.

### Mailing List

The mailing lists are explained on the Cryptix homepage. Click on the 'support' button.

### Business Model

Cryptix is provided for free, with no royalties. It is never likely to be anything else, and we (the owners) promise never to chase you for fees or royalties or whatever for any copy of Cryptix that has been released on this basis. All code was either provided on this basis, or written explicitly by the Cryptix Development Team.

Cryptix was originally written by Systemics, Ltd. The original developers believed that selling crypto code was not (and is not) a workable business. However, good strong crypto libraries were still required and were not then available.

The solution was to publish Cryptix as a freeware (or Open Source) library and encourage others to contribute, use and test the code. Then Cryptix was transferred over to the Internet community, in the guise of the Cryptix Development Team. This process is now complete, as releases from Cryptix-Java 2.2 and onwards have been substantially produced by people who have no direct relationship with Systemics.

In the meantime, Systemics specialises in financial cryptography applications.

### Support

There is no formal support for freeware users of Cryptix.

It is a freely released product, and the Cryptix Development Team has no budget for providing help or for fixing problems. We will try our best, but money-making projects come first. Often it will take us several years to get a chance to look at a question, so please be patient. Sometimes we don't ever solve problems.

Problems, bug reports and other requests should be posted to the mailgroups. We would encourage everyone to end their posts with "Has anyone else seen this?" or somesuch, and hope that someone has `:))`

The USENET newsgroup comp.lang.java.security is also a useful resource for questions about security in Java.

If anyone would like to discuss a more formal support arrangement, please mail us.

If private mail is necessary, send to any mail address listed in the feedback page on the Cryptix home page, and it will be redirected to the most appropriate place.

## Questions on "Regulations" and Patents

### Is Cryptix subject to EAR or ITAR export regulations?

No, Cryptix is available from servers located around the world.

### Can Cryptix be exported from the US?

The U.S. Government says that you should ask for approval, and that has not been granted to date by the few brave souls that have tried. The U.S. crypto debate is well documented elsewhere.

### Can I export my application using algorithms taken from Cryptix?

Not being Americans, we are not familiar with the detail of what can and can't be done.

This is an issue that you must address yourself using your own resources. You can try asking on the mailgroup, but please address your questions to other Americans who might have something to say.

If you do come up with a strategy that involves coding, feel free to talk to us about it. We can't comment on the workability of any particular solution - again, not being Americans, nor lawyers - but we can code up your requirements after some negotiation.

### Do you use the RSAref code?

No, Cryptix has its own implementation of the RSA algorithm.

### What about the RSA patent?

The patent on the RSA algorithm is only an issue for U.S. users, and maybe Canadians. Cryptix was originally written for non-North American usage, so that it is not an issue for most Cryptix users.

Attempts by U.S. users to license the patent have met with complete failure.

Note that there are alternatives to RSA. Note also that the patent expires in September 2000.

### What about the IDEA patent?

A licence from ASCOM may be required for commercial use of the IDEA algorithm. If your application does not use IDEA, then this should not apply. Alternative algorithms are provided.

### Is it legal for me to use your library?

The patent and legal aspects of this library will vary from country to country. Bert-Jaap Koops' Crypto Law Survey is an excellent summary, but for the final word you should seek professional advice locally.

## Installation

### Documentation

With release 2.2 of Cryptix-Java and beyond, we have made a big effort to improve the documentation. There is is still a long way to go, but it's better than the official "sparse" rating that we earned on Adam Shostock's freeware crypto page. Pre-built and on-line browsable documentation is listed from the Mirrors. Cryptix-Perl remains sparse.

#### Instructions for 3.x

> If you prefer to build the documentation using javadoc, first unzip the `src.zip` file that came with the JDK (if you haven't already done so), and set the JDK_SOURCE environment variable to that directory. Make sure the Cryptix source release is in the current directory, then run a script depending on your operating system:
> - Under Unix, enter

>           JDK_SOURCE=/path/to/jdk/src
>           sh util/makedocs.sh

>   Replace the first line above with "setenv JDK_SOURCE /path/to/jdk/src" for csh-like shells.

> - Under NT or Windows 95 (from a command prompt), enter

>           set JDK_SOURCE=C:\path\to\jdk\src
>           util\makedocs

> You will need a reasonable amount of free memory to do this (about 12 MB).

### How to Compile the Source Release

See the compilation guide.

### Installing Cryptix as a Static Provider

Before any of the Cryptix (3) algorithms can be used, Cryptix must be installed as a Security Provider. This involves adding a line to the `java.security` file:

        security.provider.2=cryptix.provider.Cryptix

Replace '2' by the first unused provider number, if you have changed the `java.security` file before.

A program that will make this change automatically is supplied with the release. To run it, enter

        java cryptix.provider.Install

Note that this program might not work under OS/2. You will need to repeat this command for each new version of the JDK (or other Java VM), that you install, but not for each new version of Cryptix.

Whether you change the `java.security` file manually, or via the Install program, you will need permission to write to that file. This may cause problems in multi-user Unix environments where the JDK is installed in a shared directory that you do not have permission to change. In that case, you can either ask the system administrator to do the installation, or use the alternative installation method described next.

### Installing Cryptix Dynamically in an application

When distributing an application, it may not be convenient to require the user to install Cryptix (3) statically. In this case, you can use the following line in your application (before instantiating any algorithms) to achieve the same effect:

        Security.addProvider(new cryptix.provider.Cryptix());

(If Cryptix is already installed statically, this will have no effect.)

Note that in an applet, this line will cause a security exception. We are planning changes to make it easier for applets to use the Security API without requiring extra privileges.

## Implementation Choices

### Y2K compliance

Is Cryptix Y2K compliant, and does it have any other date-related bugs?

Cryptix 3.x only uses date/time-related calls for performance measurement in the test code. Since no other part of the library, including any of the cryptographic functionality, currently relies on date or time, Cryptix will continue to function correctly on any date for which the underlying Java VM and operating system does.

The calls used for performance measurement are '`new Date()`', '`Date.toString()`' and '`System.currentTimeMillis()`'. These might produce misleading results if the current time jumps discontinuously while you are making a measurement (e.g. at daylight savings transitions, or when the computer's clock is changed). This is arguably a limitation of Java, in that there is no way to measure a duration without getting confused by clock jumps. In any case, none of the cryptographic functionality is affected.

Future planned features such as parsing of ASN.1 may have date-related code (for example, encoded ASN.1 can contain 2-digit year fields in some cases). This is likely to be handled using a fixed window from 1950 to 2049 inclusive when interpreting input. Any BER and DER output created by Cryptix will always use 4-digit year formats.

Note that development releases may contain code that has not been checked for date problems - the above statements are only guaranteed to apply to official releases.

### Gathering Random Numbers in Java

Amos Elberg writes on why some virtual machines are bad for collecting entropy:

> A couple of people have flamed me about this, and others asked for more information, so let me elaborate just a bit. A virtual machine is a correct, working implementation of Java if and only if it implements exactly the behaviors set forward in the VM specification. That specification, intentionally, leaves anything that might be impossible to achieve on a particular platform open to interpretation. The API's, however, do not always make this explicit. A good example is the `Thread.sleep(long)` call. The call is accurate to the millisecond. The VM does not require an implementation to have a clock accurate to the millisecond, or the ability to time threads that accurately.

> Those areas that are left "open" to implementation happen, not by coincidence, to be exactly the same areas that we rely on to get entropy: the interface between the deterministic, finite state machine in the computer and the non-predictable, infinite state real world. It is exactly those properties of non-predictability and infinite granularity of state that we use to get entropy. But precisely because every machine is built differently, and has a different interface to the real world, the VM spec does not assume one in particular.

> For instance, it requires that every time a key is clicked, the peer with the focus gets an event. It does not specify if those events should be handled separately, or if when keys are being pressed rapidly they should all be packaged first then sent to the component in rapid succession. It specifies that when a Thread is killed, it gets a `ThreadDeathException`; it does not specify exactly when this needs to occur. In most current implementations, it occurs when a call to native code returns.

> As a consequence of this, any code that relies on idiosyncrasies of a particular VM implementation, as all of the ideas so far put forward (and I believe all possible ways of getting entropy from the user) have, will not necessarily run on every other, or any other VM.

David Hopwood says:

> The above makes the problem of obtaining random numbers in a Java VM sound worse than it is - the purpose of the `java.security.SecureRandom` class is to provide cryptographically secure random numbers, and it's the responsibility of each virtual machine implementor to ensure that the method that it uses to do that will work with their VM. In practice, the method used by Sun's implementation (counting the number of times a thread can yield in a given time) is IMHO reasonably well-thought out, and is likely to work at least on the Java VMs currently available from Sun and its licensees.

> Since it is not completely proven, though, Cryptix 3.1 and later will use the `/dev/random` device, on platforms for which it is available, as an additional source of seed data.

### History

A brief history of Cryptix-Java, in reverse chronological order, follows.

#### V3.1

Cryptix 3.1, released July 1999 is a maintenance update to Cryptix 3.0.3, it features the following changes:

- Java 2 (JDK 1.2) compatibility.
- PGP 2.x support (NOTE: this is different from OpenPGP!).
- Numerous minor bugfixes.

#### V3

In December of 1997, the Cryptix Development Team released V3 to the public. This release represents a new transition by including the IJCE as the core architecture for cryptography in Java.

Version 3 also supports a more flexible trade-off between the performance of native code and the portability of Java: native versions of some algorithms are available for speed, but a Java version will be used if these are not present, or fail to load correctly. (Sun's "100% Pure Java" initiative specifically allows this approach for provider-based interfaces such as the Security API, although Cryptix has not yet been put forward for "100% Pure Java" certification.)

Some overhead is incurred by the IJCE being pure Java, but there is scope for significantly reducing this overhead in future versions, for cases where large amounts of data are encrypted. A great deal of attention has been paid to ensuring that the Cryptix native code does not introduce security problems through buffer overflows, incorrect memory management, race conditions etc.

The basic architecture for Version 3 is now well established, and work is progressing on new features. The next major change is likely to be support for JCE 1.2, the next version of Sun's Java Cryptography Extension.

#### V2

Version 2 of Cryptix-Java was characterised by the switch from native code to all-Java:

- 2.4.x was an external series for development of V3 distribution. Many beta testers have these test releases, but they should upgrade to V3. Many thanks for your help.
- 2.3.x was an internal series for development of V3 distribution.
- 2.2.2 was the planned release version for the IJCE, but this was recast as V3
- 2.2.0a was an interim release that included the first alpha version of the developing IJCE.
- 2.2.1 was an interim release reworked for Java 1.1.
- 2.2 was released in May? of 1997. This included more algorithms, and a beefed-up PGP section.
- 2.0 was released in February of 1997, as the first all-Java library. This was developed in response to the installation difficulties imposed by the native requirements of V1.

#### V1

The original Systemics release used native code for speed. It's still faster than the all-Java Cryptix, but this was the beginning of a lesson that Sun encoded in their write once, run anywhere mantra.

### Java Serializable Interface

Why don't the Cryptix-Java classes implement the Serializable interface?

There are a number of reasons. Here's David's list:

- For classes that use native code, it is often difficult to get at the native state in order to copy it (this is why Cipher objects are not Serializable or Cloneable, for example). Also, I'm totally paranoid about security bugs in native code, so any optional feature that makes ensuring security more complicated, as serialization does, is unlikely to be supported for those classes.

- Anyone who can cause a chosen byte stream to be deserialized can run code on the VM that is doing the deserialization (not necessarily arbitrary code, but enough to cause concern). So, use of deserialization is a potential security bug unless you're careful to make sure the input is from a trusted source. For programs that use cryptography, that's particularly worrying.

- Making a class Serializable effectively means that its private fields are now part of its public interface, since changing those fields will mean that data serialized from an old version can't be deserialized into the new version. IMHO much of the point of making fields private is so that you can change them without any compatibility problems. This can be fixed to some extent by writing explicit readObject/writeObject methods that use a fixed format, but maintaining those methods then becomes a hassle.

- Not implementing Serializable doesn't make it impossible for someone who needs serialization to use my classes. If their class has a field holding an instance of mine, they can override read/writeObject to get its state using public methods.

### Applets

Can Cryptix be used in applets?

It depends. Generally, applets are code downloaded from a remote machine. They can therefore be intercepted and replaced as they travel from the remote machine to the local machine. Adding strong crypto of the sort included in Cryptix does not protect against this in any way, as it it would be relatively easy for an attacker to change the applet in some way (applets can be decompiled, and the crypto code is published) to disable or subvert the crypto.

This problem is lessened (not eliminated) when using an applet that has been authenticated. If all of the following conditions are true, it could be useful to rely on the Cryptix library in an applet:

- the user has installed Cryptix locally, and is confident that their copy of it has not been tampered with.
- the applet is either signed, or loaded using SSL, and the user has some reason to trust the signer/web site.
- the browser supports signed applets and/or SSL.
- in the case of a signed applet, the applet doesn't rely for its security on any parameters given on the HTML page (it is possible for an attacker to copy the applet's code, with its signature intact, but change these parameters).

The reason why Cryptix must be installed locally, apart from the download time, is that some of its classes are in the java.security package, and most browsers will not let applets define classes whose names start with "`java.`".

HotJava's support for signed applets is (at the time of writing) more a proof-of-concept than anything else. In particular its key management is not currently robust enough to use for anything very significant [IMHO --David]. Netscape 4.0 is looking promising, but note that the first few releases of browsers that support signed applets are likely to have bugs in that support.

Most of the applications written to date require complete security over an insecure network, including the existence of aggressive attackers. It is for this reason that we are skeptical about the use of Cryptix for applets. Your mileage may vary.

### Use of Native Code

What are all these references to native code in the source?

We originally planned to support native implementations of the various algorithms in Cryptix for performance reasons. The current Java Virtual Machines however are so fast that they render native code obsolete. The source code still contains the native code support framework but it is not used and will be removed in upcoming versions of Cryptix.

### The Java namespace

Why is the Java namespace as it is?

In older releases of Cryptix-Java (pre-2.2) there were elements of the classes inside the `java.crypt`, `java.math` and `cryptix` namespaces.

Cryptix-Java V2.2 migrated to a local hierarchy of cryptix:

> Pre-2.2 | 2.2
> java.math | cryptix.math
> java.crypt | cryptix.security
> java.crypt.rsa | cryptix.security.rsa

> Table 3: Namespace changes in V2.2

Version 3.x has a completely different structure, and the three packages above have been deprecated:

> 3.0.x | Description
> cryptix.provider.* | The Cryptix security provider (split into subpackages for different types of algorithm)
> cryptix.util.* | Support and utility classes (split into subpackages according to function, e.g. math, test, etc.)
> java.security.* | The IJCE API
> netscape.* | Dummy classes required for Netscape VM support

> Table 4: Namespace in V3.0.x

The International JCE implementation lives in `java.security.*` and `java.security.interfaces.*`, just like JavaSoft's early-access release. According to the JCE 1.2 preview APIs, the encryption classes (i.e. those that are not exportable from the U.S.) will move to `javax.crypto`, and IJCE will change to follow the same pattern.

A few notes on other choices follow.

Cryptix should live in its own namespace (as opposed to, for example, "systemics") because it is a community resource. A lot of the work in original coding was done by people on the net, and Systemics' main assistance is in packaging. The long term goal was always to have a team of developers maintain, update and publish it independently of Systemics. This goal has been mostly realised in the current release, which includes the substantial efforts of the Cryptix Development Team, as distinct from Systemics.

Another issue is the convention of COM.company as a namespace to guarantee uniqueness. The original developers of Cryptix have adamantly rejected this Berkeleyism in a general distaste of mixing namespaces arbitrarily. More specifically, the Cryptix Development Team don't yet have a unique (or otherwise) domain address, and might not in the future. Conspiracy theorists will also wish to note the strong causal link of TLAs from .COM to NIC to SAIC to NSA ...

### JavaSoft's BigInteger

Why is there a cryptix.math.BigInteger class, when the Java API supports built-in bignum arithmetic via java.math.BigInteger?

This class was needed by earlier versions of Cryptix designed for Java 1.0.x, before java.math.BigInteger was available. It is now deprecated, but our PGP still uses it. You can find it in the OLD.jar archive for use with applications written for Cryptix 2.2.

`cryptix.math.BigInteger` has methods `toJavaMathBigInteger` and `fromJavaMathBigInteger`, that can be used to convert from one format to another. This conversion isn't terribly efficient, though.

## Compatibility Issues

### Platform support

Which Java platforms can Cryptix 3.x be used on?

Cryptix 3.0.4 and later require Java 1.1 or 1.2. Support for running on Java 1.0.2 has been dropped, because this was limiting development of new features.

> Cryptix Release | Java 1.0.2 | Java 1.1.x | Java 2 (JDK 1.2.x) | Netscape 4.x
> 2.2 and earlier | Yes | Yes [3] | Yes [3] | Yes [3]
> 2.2.0a and 2.2.1 | No | Yes | No | No
> 3.0 - 3.0.3 | No [4] | Yes | No [5] | No [6]
> 3.1.x onward | Not tested | Yes | Yes | Not tested

> Notes:

> - [3] Apart from a bug in the DES class, when compiled using a Java 1.1 compiler.
> - [4] Cryptix 3.0 to 3.0.3 were able to run on Java 1.0.2 by adding classes from a JDK 1.1 release to the CLASSPATH.
> - [6] Some users have been able to modify Cryptix 3.0 - 3.0.3 to work with Netscape.

> Table 5: Java version requirements

The Cryptix 3.1.x releases have been built and tested on these Java platforms:

- JDK 1.1.8b (on FreeBSD)
- Windows 95/NT JDK 1.1.8
- Windows 95/NT Java 2 (JDK 1.2.2)

The Cryptix 3.0.x releases have been built and tested on these Java platforms:

- Solaris JDK 1.1.3 and 1.1.4
- Linux JDK 1.1.1 and 1.1.3 (on Linux and FreeBSD)
- Windows 95/NT JDK 1.1.1 to 1.1.5
- From Cryptix 3.0.4 onward, Windows NT JDK 1.2 beta 3 (previous versions failed on JDK 1.2)
- Windows NT Netscape 4.0.1 and 4.0.4 (with or without the JDK 1.1 patch)

#### Compatibility with Cryptix 2.2

Ciphers, message digests, modes, and some support classes for Cryptix 2.2 are now provided in the OLD.jar.

However, all of the classes that were in the 2.2 release are deprecated, and we recommend that you should port over to the IJCE (see the next section) as soon as possible.

### The International Java Cryptography Extension

What is the International Java Cryptography Extension?

Cryptix 3 introduces the International Java Cryptography Extension, or IJCE for short. This complete, clean room implementation of the Javasoft specification is intended to give plug & play crypto compatibility with Java crypto from many different suppliers of cryptographic algorithms.

The IJCE includes four general cryptographic APIs (but no implementations):

- cipher interface, for either symmetric or public-key ciphers.
- mode interface, that provides such features as feedback.
- padding scheme interface, that allows block ciphers to be used to encrypt any length of data.
- message digest interface.

Onto the architecture of the IJCE, a provider can be plugged in to supply crypto algorithms such as IDEA, RSA and RIPEMD160 that meet the interface specification. In the Cryptix 3 releases, the Cryptix provider includes these algorithms and more plugged into the IJCE.

#### Compatibility with other implementations

The JCE specification is open and there are other implementations. Also, it is envisaged that there will be many implementors of providers, using the IJCE as a platform, or other JCEs. It is our intention to be conformant with the specification, and seek to provide plug & play operation with other products.

To date, no compatibility testing has been conducted. As there are a number of ambiguities within the specification, some problems are to be expected. Watch this space.

When the compatibility testing is complete, other implementations of the JCE specification, such as JavaSoft's JCE implementation, will not conflict with Cryptix if they are installed in the classpath at the same time. For the current release, make sure that JavaSoft's JCE classes are not on the classpath.

Known differences from JavaSoft's version are listed here. Any English-writing journos out there to even the balance?

## Strength, Reliability, Etc

### How Strong Is It?

Uh, it would be immoral and highly naughty of us to tell you. But here are a few "facts":

- Each release tends to have a range of secret key algorithms. DES in particular has been around, substantially unmolested since the 1970s, and can be readily used to construct Triple DES (DES-EDE3) to avoid brute-force cracking machines commonly found in certain places.

- You can use either RSA or ElGamal as public key algorithms. RSA has been around since the 1970s as well, and has survived repeated efforts to break it.

  The current implementation of El Gamal is very new, and would not be recommended for serious use just yet. ElGamal as an algorithm is somewhat newer than RSA (date?), but has been subject to a serious amount of attention, including by those at RSADSI, who are generally very careful to reveal shortcomings in competitive products :-)

- These algorithms come with the unofficial "mark of crypto quality" from the US Government. That is, Cryptix is never going to be allowed to be exported from the States under the current export rules.

- You've got the source. So you (or someone else) can look for bad bits. On the other hand, there are only about 100 companies and individuals out there that are actively using it, and it has only been published since mid-1996.

### How Can I Be Sure?

Armed with the above pseudo-facts, there are some things you can do to check out the situation:

- Read some good books. The team refers to these tomes:
  - Bruce Schneier, Applied Cryptography, 2nd edition. This is the favourite entry-level text.
  - Menezes, van Oorschot, Vanstone, Handbook of Applied Cryptography, 1997. Serious crypto-programmers find this indispendable.

- Bruce Schneier has also written an aggressive essay called Why Cryptography Is Harder Than It Looks which should encourage you to be particularly careful when using Cryptix!

- Ask on some of the crypto newsgroups if there is anything good or bad to be said. There are a lot of good people there, and if you offer some cash for some code-checking, you are bound to get some takers.

- Read the Snake Oil FAQ.

### The Advantage of Source Availability

Many people wonder why the source for strong crypto should be available. The answer is mostly to do with the high level of complexity versus the high level of risk. By making the source code openly available to a wide group of people, we hope to expose bugs and weaknesses through peer review.

Here's how David Spector puts it:

> Good, safe, well-tested cryptographic security software is like a flu vaccine. It must be extensively researched and tested to know in what kinds of situations (in the case of a vaccine, what strains of flu) it is appropriate to use and in which it is not. The ability of software to interoperate correctly with other similar software is one of these tests. Imagine a flu vaccine that kills you if you've ever had a polio or tetanus shot.

> Just like vaccines and other medicines, high-quality cryptosystems go through a rigorous set of designs, reviews, trials and peer-reviews before they should be trusted with your data (or in the case of a vaccine, your life!).

> A security system is not something you buy off the back of a truck, nor is it something that non-experts (such as faith healers or trade-magazine writers [or congressmen]) are likely to be expert at, so taking security advice from these so-called experts is a lot like going to a "psychic-surgeon"... you will probably not get what you expect, and most certainly will not get better if you are ill.

> Finally, like medicines, cryptosystems need to be re-evaluated on a regular basis to ensure that they are still effective, and are still safe to use. Since technology (and the flu) is always on the move, it's a good idea to keep ones technology (and ones flu shots) up to date.

### Which Secret Key Algorithm Should I Use?

Here are vital statistics on some of the secret key algorithms included in various releases of Cryptix:

> Algorithm | Publication Year | Pluses | Minuses
> DES | 1975 | well tested | key too short, slow
> Triple-DES | n/a | very well tested, conservative choice | three times slower than DES
> IDEA | 1991 | PGP popularity | commercial license required
> Blowfish | 1994 | fast en/decryption, popular | slow key setup
> SPEED | 1997 | very fast, variable key/block/rounds | very new, attacked in unpublished paper, no details available, but thought to be broken
> CAST5 | 1997 | Conservative design, fast, PGP5 popularity | newish
> LOKI91 | 1991 | reviewed, undergoing update for NIST (LOKI97), very fast | newish
> RC2 | ? | ? | new
> RC4TM | ? | very fast | stream cipher, tricky to use
> SAFER | 1993 | strengthened 1995 | new
> Square | 1997 | fast | very new

> Table 6: Vitally Secret Statistics

Notice the studied absence of a recommendation from the team `:))`

Some deeper comments on algorithms can be found in A Current Perspective on Encryption Algorithms by Laurie.Brown at adfa.oz.au.

The Block Cipher Lounge contains an index that directs the reader to current attacks on most current algorithms. This page is maintained by cryptographers Lars R. Knudsen and Vincent Rijmen.

For details on the support for each algorithm, see Supported Algorithms.

### Working Practice for Broken Algorithms

From time to time, an algorithm is shown by the cryptographic community to be broken. Sometimes concerns are raised, and at other times, simple flaws are rectified with simple fixes.

It is part of the responsibility of every crypto-programmer to be aware of these dynamic recommendations, and to respond in some fashion. This section discusses how we, in the Cryptix community, will attempt to respond to this challenge.

The working practice that we use is

1. A useful collection of information (links, etc) is maintained to assist individual choice.

2. The Cryptix Development Team does not formally recommend one algorithm over any other.

3. When concerns are raised, warnings are mailed to the list (higher priority), and documentation is updated to reflect the concerns (follows in due course).

4. Code will continue to function without change; no properties or warnings will alert the users. It is up to the users to know what is good and bad.

5. If the cryptographic community are judged to have collectively decided that an algorithm is unworthy of further consideration, support for an algorithm may be dropped, over time.

This seems to best fit the particular roles, skills and needs of cryptographers, developers and users alike. It takes into account these considerations:

- We are not cryptographers!

  This is changing over time, and our cryptographic skill is improving, but our role of providing code is best kept independant of the cryptographic role of advising on good algorithms.

  By separating the concerns of code from algorithm, we can hopefully be less biased.

- Cryptographers, in all their naked humanity, are not infallible. Sometimes serious breaks get hidden behind vague information, at other times, commercial cryptographers will dress up the information in the best light for their companies and own reputations. The press love it, but it makes the programmer's job harder.

- Often, a fix can repair the damage. Given the chance, upgrading to a new variant is far easier than changing over to another algorithm.

- The development team have got enough to do without trying to be completely reliable on the impossible issue of today's best algorithm. Developers need an efficient solution, as well as users.

- Some systems can still rely on an algorithm for which concerns have been raised. Even a completely broken algorithm can find an economic use as just snoop protection, and we are not in a position to judge other's usage of an algorithm.

  The canonical example is DES. Even though this is a forgettable algorithm by all programming standards, it is endemic in the computing infrastructure. For this reason, support is unlikely to be dropped for a decade or more, but you should take every chance to migrate to something better.

- Each and every cryptographic programmer should know their stuff. Best to not make things too easy `:))`

- In general, a far greater danger exists in a shoddy implementation of the code that uses the algorithm. Rare indeed is the break of an open algorithm reported as being conducted in a commercial setting; far more frequent is a software engineering or architecture failure.

- Cryptix is active in helping cryptographers develop new algorithms, for example with the AES Quest. Aside from being a lot of fun, we see that as essential to keep alive the skills of the free international cryptographic community.

  Without a way to get new algorithms out there and being used, when by rights these algorithms have not been properly tested, there would be no way for any algorithm to become tested and acceptable.

  To overcome this bootstrapping problem, we encourage cryptographers and users alike to try out new algorithms. And to take the knocks when they are broken, of course. In the long run, this will help to ensure a suitable supply of algorithms suitable for dynamic challenges on the Internet.

As well as not being cryptographers, we are not bureaurats. The above is working practice, not policy nor dogma. It is subject to change for reasons of improvement, experimentation, forgetfulness, and whim.

Please send any and all comments to the mailgroup.

## Performance

Performance is not a big concern with Cryptix. Most hackers are concerned with getting code out there right now if not sooner. And most applications run on machines like PCs that these days munch through crypto as if it wasn't there.

However, there are still some good reasons for considering performance. Sometimes, you need to know whether your application needs to use the high performance options such as C or assembler - if you can get away without it this means big savings in complexity and hassle.

Performance programs make great examples, as they clearly show how to use the algorithm without getting into real-life considerations that tend to obscure things. It's also got to be said that speed of one's favourite algorithm is a competitive ego-inflating sport, of which we need many more on the Internet `:))`

What follows are those Cryptix Application Notes (CANs) that cover the issue of performance and tuning. Actually that is most of them but that is not really the issue ...

### Hashes

In CAN-1, author Raïf Naffah compares the speed of several hash functions.

### Block Ciphers

In detail, CAN-2 compares the speed of several symmetric block ciphers.

### Public Key Algorithms

To do.

### In Search of Faster Encryption

If you are worried about performance, then you should really be using a high performance language like C for the algorithm itself. Real crypto-grinders like to hand code the inner loops in assembler, spending 100s of man-hours looking for savings of cycles. Of course, hardware is where it's really at...

If, however, you really want a faster algorithm in Java, CAN-3 describes how the author speeded up the LOKI91 algorithm by a factor of 20, taking it from the worst to the equal best.

## Known Features

These are things that people find as bugs, but are generic to the nature of cryptography, and are sardonically called features by the more enlightened `:-)` It helps to know of them in advance of finding them as bugs.

### Using Cryptix with non-writeable Java

I'm doing my thesis on Unix machines at University, and I can't Install into the JDK directory (it is not writeable). How do I dynamically add the Cryptix Provider?

Call

> `Security.addProvider(new cryptix.provider.Cryptix());`

before using any algorithms. Also read this bug entry.

### RSA doesn't work

Most of the RSA functions require a key size that matches or exceeds the length of data block that is passed. Some things will work with smaller keys, but for everything to work, use a minimum key size of 384 bits.

This not a bug, but a feature `:))` It is also recommended by RSA themselves for some of their products.

This property of RSA also means that if you try to encrypt a piece of data twice with different public keys of the same bit length, and the second key is less than the first, the result will not necessarily decrypt correctly if the corresponding private keys are used in reverse order. This is also not recommended because there may be cryptanalytic attacks that apply only to this kind of multiple encryption.

A better way of doing multiple encryption in series (where both of two private keys are needed to decrypt), is to generate two random secret keys for a symmetric algorithm, encrypt these separately using the public keys, and encrypt the plaintext using each secret key in turn. I.e. the result will be the three values:

- ERSA[P1](format(K1))
- ERSA[P2](format(K2))
- Esymmetric[K2](Esymmetric[K1](plaintext))),

where P1 and P2 are the public keys, K1 and K2 are random secret keys, and format is a function that converts data to a secure block format (for example, PKCS#1). Decryption is left as an exercise for the reader. This can be extended to more than two RSA keys, simply by using the same number of secret keys.

### SHA gives unexpected results

Some users have found that SHA gives unexpected results. The problem may be that there are two variants of SHA, and you have one but are expecting the other.

To distinguish, these are generally called SHA-1 and SHA-0. The variant SHA-1 is based on a suggestion made by the NSA, and is widely thought to be slightly better. It is recommended.

In Cryptix 3, you would normally construct these message digests using

> `MessageDigest.getInstance("SHA-1")`, or
> `MessageDigest.getInstance("SHA-0")`.

`"SHA"` can be used as an alias for `"SHA-1"`.

## Known Bugs - Java

Sorted with most recent first.

### Dynamically added providers might be uninstalled unexpectedly (V3)

When using Sun's implementation of JCA (as Cryptix versions 3.0 to 3.0.3 inclusive do) with JDK 1.1, providers that have been added dynamically (i.e. using `Security.addProvider`) might be uninstalled as your program is running, leaving only the providers specified in the `java.security` file.

This is a result of JDK 1.1 not correctly implementing the language specification for class unloading (as clarified at http://www.javasoft.com/docs/books/jls/clarify.html) - in particular it will sometimes unload classes loaded by the default ("system") classloader.

If the `java.security.Security` class is unloaded, the static fields of that class, including the field that holds the list of installed providers, will be lost. When the class is reloaded, only the providers in the `java.security` file will be reinstalled.

A workaround is to put

      private static final Class workaround = java.security.Security.class;

in your main class. This will make sure there is a reference to the `java.security.Security` class at anytime.

### Ciphers with a variable block size can cause an ArrayOutOfBoundsException when used in a mode other than ECB (V3)

If a cipher with a variable block size (e.g. SPEED) is set to a block size larger than the default, and is used in a mode other than ECB, an ArrayIndexOutOfBoundsException will be thrown when data is encrypted or decrypted. This happens because the array created to store the initialisation vector is created before the block size has been set, and is not long enough to store an actual block.

A fix for this problem will be included in Cryptix 3.0.4.

### Comments about overlapping arrays in some algorithm classes are inconsistent with the implementation (V3)

In Cryptix 3.0 to 3.1.0 inclusive, the comments for `Cipher.engineUpdate` (and implementations of that method in cipher and mode subclasses), say that the in and out parameters may be the same array, and that the input and output regions may overlap. For some algorithms (e.g. RSA, and the mode CBC), the code for `engineUpdate` would not be correct under that assumption.

In fact the comments need to be changed; IJCE's implementation of the Cipher class will ensure that cipher and mode `engineUpdate` methods are never called with overlapping input and output regions.

It has been agreed on a mailing list for JCE implementors that the Cipher class should do this, but at the moment, we do not recommend that the Cryptix provider be used with any JCE implementation other than IJCE.

### 'finalbuild' compilation script doesn't work (V3)

There are two problems with the `util/finalbuild` script intended to be used to compile the 3.x source releases:

- The Windows version (`finalbuild.bat`) uses batch extensions specific to Windows NT, that are not supported on Windows 95.
- On all operating systems, some of the files needed (in particular, the `src10` directory), were missed out of the release.

### ElGamal encryption doesn't work (V3)

Attempting to get an ElGamal cipher implementation using `Cipher.getInstance("ElGamal")` will throw an exception, for example:

    java.lang.IllegalArgumentException: IJCE does not support ciphers for which implPadding == true
            at java.security.Cipher.(Cipher.java:290)
            at cryptix.provider.elgamal.RawElGamalCipher.(RawElGamalCipher.java:79)
            at java.security.IJCE.getImplementation(IJCE.java:357)
            at java.security.Cipher.getInstance(Cipher.java:476)
            at java.security.Cipher.getInstance(Cipher.java:439)
            at java.security.Cipher.getInstance(Cipher.java:382)
            at [...]

The ElGamal cipher implementation is experimental code, and is not yet supported or tested (it should not really have been enabled in the Cryptix.properties file).

ElGamal will not be fixed in Cryptix V3. Our upcoming JCE will contain a working ElGamal implementation.

## Copyright and License

### Ownership

This library includes, or is derived from software developed by (and owned by) the following:

The Cryptix Development Team

- Paulo Barreto <pbarreto@cryptix.org>
- Ian Brown <I.Brown@cs.ucl.ac.uk>
- Jeroen van Gelderen <gelderen@cryptix.org>
- Ian Grigg <iang@cryptix.org>
- Sascha Kettler <kettler@bwl.uni-mannheim.de>
- Erwin van der Koogh <erwin@cryptix.org>
- Raïf Naffah <raif@fl.net.au>
- Edwin Woudt <edwin@cryptix.org>

Inactive members include:

- Jill Baker <jbaker@pobox.com>
- David Hopwood <hopwood@zetnet.co.uk>
- Gary Howland <gary@hotlava.net>
- Zoran Rajic <zox@fly.cc.fer.hr>
- Systemics, Ltd <info@systemics.com>
- Mike Wynn <Mike.Wynn@alien-r.ace.co.uk>

Other contributors

- George Barwood <george.barwood@dial.pipex.com>
- Antoon Bosselaers
- Lawrence Brown <lpb@cs.adfa.oz.au>
- George Chung <gchung@openhorizon.com>
- Richard De Moliner <demoliner@isi.ee.ethz.ch>
- John F. Dumas <jdumas@zgs.com>
- Peter Gutmann <pgut001@cs.auckland.ac.nz>
- Uwe Hollerbach <uh@alumni.caltech.edu>
- Geoffrey Keating <geoffk@discus.anu.edu.au>
- Jonathan Knudsen <jonathan@oreilly.com>
- A. M. Kuchling
- Matthew Kwan <mkwan@crypto.cs.adfa.oz.au>
- Jerry McBride <mcbrides@erols.com>
- Andrew E. Mileski <aem@netcom.ca>
- NIST
- Bryan Olson <bryan.olson@uptronics.com>
- Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
- RSA Data Security, Inc.
- Bruce Schneier <schneier@counterpane.com>
- Thomas Wu <tjw@xenon.stanford.edu>
- Eric Young <eay@mincom.oz.au>
- Yuliang Zheng <yzheng@fcit.monash.edu.au>

Do not mail these people (either from the Cryptix Development Team or external contributors) with requests for help. Some of them have never even seen Cryptix, and the rest worked on very specific parts. Joining the mailgroups is the only way to seek help.

### Comments on Ownership

As software, Cryptix is owned by the programmers who wrote the original code. This is a diverse group of developers across the net, of which programmers in the Cryptix Development Team are the majority, but not the only contributors.

As a brand name and trademark, Cryptix is owned by Systemics. The use of the Cryptix trademark is a mechanism to assert rights over the product, and protect it from fraudulent attribution claims. Systemics asserts these rights on behalf of the owners (the developers) although it doesn't seek to own each line of code. The individual developers rights are in addition to and are not superceded by any rights that Systemics asserts under the Cryptix License, below.

### The Cryptix License

Cryptix-Java V2.2 and later is covered by the following license:

Copyright © 1995-1999 Systemics Ltd (http://www.systemics.com/) on behalf of the Cryptix Development Team (http://www.cryptix.org/). All rights reserved.

This library and applications are FREE FOR COMMERCIAL AND NON-COMMERCIAL USE as long as the following conditions are adhered to.

Copyright remains with Systemics Ltd, and as such any Copyright notices in the code are not to be removed. If this code is used in a product, the Cryptix Development Team should be given attribution as the author of the parts used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
   This product includes software developed by the Cryptix Development Team (http://cryptix.org/)

THIS SOFTWARE IS PROVIDED BY SYSTEMICS LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The licence and distribution terms for any publically available version or derivative of this code cannot be changed, i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence].

## Trademarks

Cryptix is a trademark of Systemics Ltd.

Sun, JavaSoft, JDK, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc.

Microsoft, Windows 95 and Windows NT are registered trademarks of Microsoft Corp.

Irix is a registered trademark of Silicon Graphics, Inc.

RC4 is a trademark of RSA Data Security, Inc.

Other brand, product, and algorithm names may be trademarks or registered trademarks of their respective holders.

Copyright © 1995-1998 Systemics Ltd
on behalf of the Cryptix Development Team.
All rights reserved.
Cryptix is a trademark of Systemics Ltd.
Also see trademarks section.