Cryptix README or Readme Src or Readme Bin
Frequently Asked Questions
Javadoc index or Help
Documentation
Java Cryptography Extension Specification
Utility scripts
Copyright and License

Cryptix

Development

Team

Cryptix TM
Frequently Asked Questions

$Revision: 1.13 $
$Date: 1997/12/21 18:32:36 $

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


Table of Contents

Return to the Cryptix Index. 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.

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

Mailing lists exist for the users of Cryptix. Here are the terms:

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:

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

Instructions for 2.2.0a

As above, but the "makedocs" script is in the doc/ directory.

Instructions for 2.2

All the documentation is in javadoc format. To build the documentation, under Unix, try this group of commands within the directory you extracted the source:
    mkdir doc
    CLASSPATH=. javadoc -author -d doc $(find cryptix/* -type d -print | sed -e 's,/,.,g')
That is, find all the directories, convert the names to package dot format, and pass the list to javadoc, which will produce doc/packages.html which is a browsable file.

How to Compile the Source Release

This section is specific to Cryptix-Java 2.2.0a, 3.x and later.

To compile the Java source, make sure the source release is in the current directory, then run a script depending on your operating system:

Also see the compilation guide.

To compile the native library source, see the file native/README.txt.

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 library and encourage others to contribute, use and test the code. Then Cryptix has been transferred over to the Internet community, in the guise of the Cryptix Development Team. This process is substantially complete, as releases from Cryptix-Java 2.2 and onwards have been substantially produced by people who have no direct relationship with Systemics, whose role is relegated to one of distribution and support to the development team.

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 days 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 on the Systemics home page, and it will be redirected to the most appropriate place. Please mark such correspondence as private, as Systemics commonly forwards bug reports directly to the mailgroups or developers or both.

FAQ History

This is the history of the FAQ:
$Log: FAQ.html,v $ Revision 1.13 1997/12/21 18:32:36 iang dist_common had same bug - error in $type Revision 1.12 1997/12/21 00:54:37 iang fixed compilation/testing notes to point to guide/*.html Revision 1.11 1997/12/20 19:43:23 iang added doc/index.html as a help file for building/downloading of the Javadoc doco. Hooked in to all top indexes. I think I need a script to update all indexes automatically, this will become too clumsy to maintain. Revision 1.10 1997/12/20 01:44:57 iang more mods, more integration with distribution Revision 1.9 1997/12/19 19:09:20 iang Revision 1.8 1997/12/19 06:32:33 hopwood Revision 1.7.1 1997/12/18 hopwood Revision 1.7 1997/12/18 12:03:51 iang Revision 1.6 1997/12/18 10:18:17 iang Revision 1.5 1997/12/14 05:40:36 iang Revision 1.4 1997/12/14 05:28:41 iang Revision 1.3 1997/12/07 06:47:07 hopwood Revision 1.2 1997/12/07 06:44:08 hopwood Revision 0.1.22 1997/11/18 Revision 0.1.21 1997/10/30 Revision 0.1.20 1997/10/30 Revision 0.1.19.1 1997/10/29 Revision 0.1.19 1997/10/14 Revision 0.1.18 1997/10/14 Revision 0.1.17 1997/10/11 Revision 0.1.16 1997/09/23 Revision 0.1.15 1997/09/18 Revision 0.1.14 1997/09/16 Revision 0.1.13 1997/09/10 Revision 0.1.12 1997/09/09 Revision 0.1.11 1997/09/08 Revision 0.1.10 1997/09/06 Revision 0.1.9 1997/08/27 Revision 0.1.8 1997/08/26 Revision 0.1.7 1997/08/25


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 is unlikely to be granted, in our opinion. The U.S. crypto debate is well documented elsewhere.

Do you use the RSAref code?

No, we use our own implementation of the RSA algorithm.

What about the RSA patent?

The RSA patent 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. We know of no attempt by U.S. users to license the RSA patent on this basis. Note that future releases will include alternatives to RSA.

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.


Implementation Choices

History

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

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.

Currently, V3 is still in the early phases, but work is progressing to round it off. 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:

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:

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 signed applets. If all of the following conditions are true, it could be useful to rely on the Cryptix library in an applet:

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

Why is native code used, rather than pure Java or Perl?

Cryptix 1.x required native libraries because no pure Java (or Perl) code was written for the cryptographic algorithms, and because Java 1.0.2 did not have bignum (arbitrary length integer) support built-in.

Cryptix-Java 2.2 and later have pure Java versions for all algorithms. The performance of these is adequate for most purposes, but it can be improved on by also supporting optional native code. Currently this has been written (but not yet released) for the Blowfish, IDEA, LOKI91, SAFER, and Square ciphers, and for the HAVAL and RIPEMD128/160 message digests.

In 3.x the treatment of native libraries is as follows:

If a native library is available for a particular algorithm and platform (i.e. it is in the cryptix-lib/bin directory), it will be used automatically. There is an option in the Cryptix.properties file that can be used to disable the search for native libraries, in case it causes problems for a particular VM.

The target VM must support JNI (the Java Native Interface), in order for native code to be used.

[Tables 1 and 2 will contain benchmarks of Java vs. native code for each algorithm; these have not been compiled yet.]

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

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

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.) may move to javax.crypto, in which case IJCE would 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 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 ...

RSA Examples

I cannot find any examples on RSA?

Cryptix-Java 2.2 includes some fine RSA examples in cryptix.examples (thanks Patrick).

Earlier releases had no examples; you were supposed to do it all from the theory. For those with no access to the relevant information, here is a scanned-in page of the relevant RSA section from Bruce Schneier's Applied Cryptography, used with permission.

As part of the JCE support, Cryptix-Java 3.x and later have an additional RSA implementation which uses java.math.BigInteger; this does not have any examples yet.

JavaSoft's BigInteger

Is Cryptix going to move over to JavaSoft's BigInteger?

Yes. New code (for example the El Gamal implementation) is being written to use this class in preference to cryptix.math.BigInteger. For the time being, cryptix.math.BigInteger will be kept - the reasons for doing this include:

In release 2.2.0a and later, 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.

Java 1.1

What about the new Java 1.1 language specification?

There are three new features of Java 1.1 that Cryptix can make use of:

Releases of Cryptix up to 2.2 do not use any Java 1.1 features, and are reported to compile and run under both Java 1.1 and Java 1.0.2 (although keep an eye on the bugs).

Cryptix 3.x compatibility

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

Cryptix 3.x will run on both Java 1.0.2 and Java 1.1, but can only be recompiled on Java 1.1. When it is running on a 1.0.2 VM, the following features are not supported:

Trying to use a class that is missing under Java 1.0.2 will result in a NoClassDefFoundError being thrown, with the class name as a detail message. If your application needs to use these features whenever they are available, but fall back to another mode of operation otherwise, it can do so by catching NoClassDefFoundError.

It is possible to supply the missing classes by unzipping the classes.zip file included with JDK 1.1.1 or later, moving the classfiles from the java/security/* and java/security/interfaces/* directories to their own directory tree, and adding the root of this tree to the CLASSPATH (before cryptix.zip). This may be useful when running Cryptix with Java implementations that do not yet support the JCA libraries, such as Kaffe. It isn't possible for us to distribute these classfiles with the release, since the Java Runtime Environment license does not allow that.

Compression support and the new RSA/ElGamal implementations will still not work correctly even if these files are on the CLASSPATH, because they rely indirectly on native libraries that are only supplied with Java 1.1.

In summary:

Cryptix Release Runs on Java 1.0.2? Compiles on Java 1.0.2? Uses Java 1.1 features?
2.2 and earlier Yes Yes No
2.2.0a No No Yes
2.2.1 No No Yes
3.0.x Yes No Yes
3.1 ? (planned) No No Yes

Table 4: Java version requirements

Note: "Java 1.1" refers to JDK 1.1.1 or later. JDK 1.1.5 is the latest bug-fix release, and should be used in preference to the earlier releases if it is available for your platform.

On Windows, speed is significantly improved if you install the JIT performance pack (note that this requires an environment variable to be set before it is enabled - see the README that comes with it).

The Cryptix 3 release has been built and tested on these Java platforms:

Cryptix has not been tested on browsers other than Netscape 4.0.4.

Compatibility with Cryptix 2.2

Cryptix 3 includes only minimal support for compatibility with the previous release. Currently, this is simply the ciphers IDEA and Blowfish, which amounts to about 5% of what would be required for full compatibility.

This should improve in future maintenance releases, but it will never be 100% there. You should plan to port over to the IJCE (see the next section) as soon as possible.

The immediate next target is the pure crypto interfaces. After that, we might get PGP working with the IJCE in compatibility, but bear in mind that this is possibly going to be overtaken by another internal project to rewrite the PGP code to both use the IJCE and to support multiple algorithms.

All new work by the team is based on the IJCE.

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):

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.

Compatibility with Cryptix 2.2

Cryptix 3 includes only minimal support for compatibility with the previous release. Currently, this is simply the ciphers (IDEA, Blowfish, SPEED, DES), which amounts to about 5% of what would be required for full compatibility.

This should improve in future maintenance releases, but it will never be 100% there. You should plan to port over to the IJCE as soon as possible.

The immediate next target is the pure crypto interfaces. After that, we might get PGP working with the IJCE in compatibility, but bear in mind that this is possibly going to be overtaken by another internal project to rewrite the PGP code to both use the IJCE and to support multiple algorithms.

All new work by the team is based on the IJCE.

Compatibility with Java 1.0.2

As mentioned earlier, the following classes are not supported when IJCE is running on Java 1.0.2: The rest of java.security.* is fully supported.

Future versions may drop support for Java 1.0.2, so you should plan to move to Java 1.1 soon.


Working with the Team

Future Directions

Cryptix development is storming ahead. Here are some of the features the team is busy with:

If you would like to help add something to Cryptix, announce your intentions on the mailgroups or get in touch with Systemics. That way we can avoid duplicating effort, and can enhance Cryptix even further!

Can you add the XYZ algorithm?

The team is adding algorithms with every new release. There is no particular schedule for this, as there is now a full set of basic algorithms. The biggest hole is the lack of choice in public key cryptography, and the team is working hard on this.

You can always add according to your needs, and you can also publish an alternative release. Indeed we would hope that you share with the free world any improvements.

If, however, you find yourself needing a certain part that is not included, and you think it is more efficient for a team member to do it, then contact us. We are always willing to adjust priorities for some financial incentive. A number of features and algorithms have been added after negotiation with interested parties.

Do you want help in coding the XYZ algorithm?

Yes Please! It is our intention to publish a full, open, free strong crypto library.

Any algorithms that you can code up and get going will be gratefully received. We can't promise getting it into any particular release, but we'll do our best.

Caveat Freedom Fighters: some programmers live in states that do not believe in freedom of speech and the right to communicate privately. If you happen to live under such conditions, then we would advise you to treat the mailgroup as monitored communications.

In that event, you could mail any address on the home page to establish communications, and use a PGP key for any sensitive mail. If you have very special problems, let us know, there may be something we can do.

Special note for Americans: current interpretation of the Commerce rules indicates that you can export printed crypto. So, if you happen to have some useful stuff, you can print it out and post it to us. Please email for a useful address of a Cryptix Development Team member, who will scan it in and get it working.

Can I help with Cryptix and learn Java at the same time?

If you are learning crypto or the language, you should be aware that in general Cryptix is for serious crypto hacking, and whilst we all appreciate help, this is not an ideal learning environment.

However, if you are still keen to get involved, then try one of these strategies.

Pick an area where nobody is working heavily. I.e., steer clear of the IJCE and PGP areas. These areas are moving very fast and you will find your efforts will be overtaken very quickly, unless you are working closely with the authors.

A good place to start is to do a secret key algorithm that has not been done before. Ask for a list of ones that are outstanding. These are nicely self-contained and have a good API to work with, as well as generally good source and doco to help from alternative sources (see existing algorithms and CAN-3). Plus, more algorithms are always useful.

Another good possibility is to find an area that you are interested in and write an example program, unit test or documentation for this, possibly in co-operation with the programmer(s) working in that area. This will introduce you nicely into the area at an entry level, which is generally enough for 95% of any future needs. And these things are definitely appreciated.

Is Cryptix Suitable for Student Programming?

Cryptix is probably not stable enough yet for short term exercises, especially those where you want to get in, get the coding done and get the assignment turned into marks. Most areas are not documented to that standard, although the core crypto is getting better, and one University has used Cryptix for a series of exercises (that we know of).

Please note that the development team cannot provide any support for student activities of this nature. Notwithstanding this, tutors on the Cryptix mailgroups would be welcome to ask questions.

In contrast, Cryptix is probably suitable for a major project (such as is normally required for a masters or final year undergraduate degree). Where you have a chance to get in and read some of the code and work out what is going on, then you will be rewarded with a good platform for building all sorts of exotic secure applications. Email us with your intentions as we may be able to help.

Two final year students have found Cryptix fruitful, one in progress and another has published the Enigma program.


Reference

More Freeware Crypto

More Java Crypto

Try the rest ... then come back for the best :-)

More Perl Crypto

None that I know of so far.

Fame and Fortune

This is the first serious writeup of Cryptix in the press that we know of: 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":

How Can I Be Sure?

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

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 well tested, conservative choice three times slower than DES
IDEA 1991 PGP popularity commercial license required, newish
Blowfish 1994 fast, popular new
SPEED 1997 very fast, variable key/block/rounds very new, unreviewed
CAST5 ? ? ?
LOKI91 1991 reviewed, undergoing update for NIST, very fastnewish
RC2 ? ? new
RC4 ? ? new
SAFER ? ? new
Square ? ? very new

Table 5: Vitally Secret Statistics

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


Known Bugs - 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.

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:

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.

PGP-encrypted data does not decrypt

Conventionally encrypted files from PGP by default contain compressed data packets, which need to be decompressed before decryption.

Alternatively, you can make sure that the data is not compressed by applying the PGP flag +compress=off at the encryption phase.

Under Cryptix-Java, you need at least Java 1.1 and Cryptix-Java 2.2 for the decompression to be available.

SHA gives unexpected results

Some users have found that SHA gives unexpected results. This is generally because 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 2.2, SHA-1 is implemented by the class cryptix.security.SHA. SHA-0 is implemented by cryptix.security.SHA0, and is present for compatibility reasons.

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".

Unfortunately, in the earliest versions of Cryptix, the programmers themselves fell into the same trap. Cryptix-Java V1 and Cryptix-Perl V1.0 both had only the SHA-0 original algorithm (named as SHA).


Known Bugs - Java

Sorted with most recent first.

T-DES encrypt sequence reversed (2.2 patch)

In a patch release to V2.3 called iang_secret_key there was an early implementation of Triple DES. The sequence of key usage in the encrypt-decrypt-encrypt cycle was reversed. As the test data was self-generated, this error propogated instead of being caught.

The effect of this reversal was to make the code non-compatible with any other implementation.

The V3.0 DES-EDE3 implementation fixes this. To fix the TDES.java in the patch release, reverse the key usage in the blockEncrypt() and blockDecrypt() methods to be 1-2-3 and 3-2-1 respectively. Note that the test data will now be wrong, get the test data from V3 (TestDES_EDE3.java) if needed.

The V3.0 release still has the same fundamental shortcoming that the data was self-generated.

Weak Armoured Messages Generated

Brien Oberstein <brien.oberstein@gs.com> writes:
    > Browsing through the source for the pgp implementation I noticed
    > a huge weakness in the PGP implementation.  The idea key generation
    > in pgp.ArmouredMessage is created by:
    >
    > String keySeed = String.valueOf( date.getTime() * Math.random() );
    > byte ideaKey[] = MD5.hash( keySeed );

Yes, this is a known problem. It's fixed in the current (unreleased) source tree, but a temporary, Java 1.1-only solution is to replace the above lines with:

    byte[] ideaKey = new byte[16];
    java.security.SecureRandom random = new java.security.SecureRandom();
    random.nextBytes(ideaKey);
Since this was a known bug it should really have been put in the FAQ, though. We apologize for that not happening - it's here now.

Alternatively, there is a fixed ArmouredMessage, that also has the ability to read CompressedData packets from PGP messages up at Ian's Enigma site and also in the patch directory.

If you want to read PGP messages containing compressed data, you also need to get the updated CompressedData.java (same places). If you haven't already got the fixed Base64.java, which allows PGP 5 to read Cryptix messages, get that as well.

Base64 bugs cause PGP failures

Recent usage with different versions of pgp (especially PGP5) have found a number of bugs in the cryptix.mime.Base64 class. There is a new class in the patch directory.

Be warned that there are ongoing bugs in this area. Notably, signatures produced by Cryptix for odd-length keys are rejected by PGP5 variants, and in another variation, all PGP2-5 (C code-based) products reject any Cryptix generated signature. Watch this space.

BigInteger or BigNum.byteLength() returns wrong value (V2)

The all-Java version of BigNum (Cryptix 2.2.x and earlier) has a bug in the byteLength method. This method should always return the length of the array that would be returned by BigInteger.toByteArray(). In the file cryptix/math/BigNum.java, change the implementation of byteLength to:

    public int byteLength()
    {
        if (native_link_ok)
        {
            return bignum_bytelen();
        }
        else
        {
            return ((bitLength( this ) + 7) / 8);
        }
    }

Security with applets

Security bugs exist in Cryptix-Java 2.0 and 2.2 (and probably earlier releases) if they are put on the CLASSPATH, and this CLASSPATH is also used by a web browser. The problem is that Cryptix is then considered to be trusted code, and can do file access, so when it is installed on a machine that also runs HotJava or Internet Explorer, untrusted applets can do file access via Cryptix.

For instance, a few of the example programs allow arbitrary files to be read or written to. This attack doesn't work in Netscape 3.0 or later, because the Netscape VM requires permissions to be explicitly granted before they can be used, but it is a potential problem for Netscape 2.x, HotJava, and MSIE.

To fix all the security bugs found so far, upgrade to Cryptix 3.0 when it is released. This release has been reviewed for bugs of the type described above, although we cannot guarantee that all of them have been fixed.

Note that Cryptix-Java was not originally designed with applets in mind - see the comments on applets and security.

RSA Mod Mul (V2)

The infamous mod_mul_recip bug in Cryptix 2.x versions now has a suggested fix. In the file cryptix/math/BigNum.java comment out the lines shown:

    if (val != 0)
    {
        r.len = 1;                  // HERE

        // If LONG
        // r.n[0] = val & 0x7FFFFFFFL;
        // If not LONG
        r.n[0] = val & 0x7FFFFFFF;  // HERE

        r.negative = (val < 0);
    }
and add the following code (only the last line in the block survives):
    if (val != 0)
    {
        // If LONG
        // r.n[0] = val & 0x7FFFFFFFL;
        // r.len = 1;
        // If not LONG
        // r.n[0] = val & 0x7FFFFFFF;

        //
        // only 30bits uses NOT 31 !!
        //
        if ( (val & 0x40000000) == 0 )
        {
            r.n[0] = val & 0x3FFFFFFF;
            r.len = 1;
        }
        else
        {
            int[] t = r.n;
            if ( t.length < 2 )
            {
                t = r.n = new int[2];
            }
            t[0] = val & 0x3FFFFFFF;
            t[1] = 1;
            r.len = 2;
        }

        r.negative = (val < 0);
    }

This is due to the big number only using 30 bits per int, not 31 bits (which is how many bits of magnitude there are in a 32 bit int).

We haven't seen any mod_mul_recip bugs for a long time, so Mike has earnt lots of beers.

DES fails tests (V2.2 - Java 1.1)

DES compiled under the later compiler versions seems to enforce the type rules more rigourously (Java 1.1 and some non-Sun tools such as Kaffe).

A new DES class that fixes a number of bugs with a variety of tools is available in the patches directory. The test code in this class acts differently as it is rewritten to go with unit tests coming in forthcoming releases (see the iang_secret_patch2.zip), but should be compatible otherwise.

If you want to change the source yourself, look for the method returns of longs (there are 4 lines to look for) and change this:

    return l << 32L | r & 0xFFFFFFFFL;
to
    return (long)l << 32 | r & 0xFFFFFFFFL;

Notice the useless 32L as well as the cast of l (that's ell for left, not the number 1). This is fixed in Cryptix 3.x

Occasional hash is wrong (V2.0)

If the length of the data being hashed is 64x+55 bytes long, then the hash returned will be wrong. The problem is in the following functions of java.crypt.MD5 and java.crypt.SHA:
    private byte[] java_digest()
    {
        ...
        if (pos >= (DATA_LENGTH-8))
To fix, simply drop the equality condition to:
        if (pos > (DATA_LENGTH-8))

Both MD5 and SHA are affected. This is fixed in 2.2 and later.

Secret encryption won't decrypt (V2.0)

If you are using a Microsoft platform, the test program in cryptix.examples will fail. This is due to it filtering the data as text, which results in the OS converting NL to CR/NL.

String Integers are incorrect (V1.1)

In V1.1, the BigInteger.toString() method sometimes returns incorrect values. For example:

    BigInteger a = new BigInteger(1000);
    BigInteger b = new BigInteger(900);
    BigInteger r = new BigInteger;
    r.mul(a, b);
    System.out.println("Result: "+r);
gives 1293216 as a result. Other values work fine.

To fix the source, modify the toString method in BigInteger.java, changing the following line from:

    returnBuffer.append( buffer[0] & 0x0F );
to:
    returnBuffer.append( hexToAscii( buffer[0] & 0x0F ) );


Bugs - Perl

Prime Tests fail (Perl 5.004)

After upgrading to Perl 5.004, a bug appeared in BigInteger::Math::TestPrime, that causes some of the tests to fail.

The bug is in the files Math-Systemics/Math/TestPrime.pm and Crypt-Systemics/Crypt/RSASecretKeyPair.pm. The line:

    Math::BigInteger::mod_exp($r, $x, $p1, $p) || return 0;  
should be changed to:
    Math::BigInteger::mod_exp($r, $x, $p1, $p);
since mod_exp doesn't return a value (and in Perl 5.004 this is what actually happens).

Compile error (gcc)

Using gcc might give compile errors complaining about undefined u_int16_t, u_int32_t within DES and IDEA.

One fix is to add this include directive at the top of the des.h and idea.h header files:

        #include <sys/bitypes.h>
If this (portability) file is not on your system, you will need to hand craft something that specifies the types. It would look something like this (from Linux):
        typedef /*signed*/ char            int8_t;
        typedef unsigned char            u_int8_t;
        typedef short                     int16_t;
        typedef unsigned short          u_int16_t;
        typedef int                       int32_t;
        typedef unsigned int            u_int32_t;
        typedef long long                 int64_t;
        typedef unsigned long long      u_int64_t;

This issue has been reported (and this fix works) on Solaris 2.4, 2.5 and DEC OSF 3.2.

(Thanks, David).


Applications

Which applications use Cryptix?

Name Description Author Download Status Cryptix Release
BackOnline Internet+intranet backup management Divya, Inc (commercial) crypto being added 3.0 (Java)
MST9000 Product Data Management (PDM) Modultek Oy (commercial) commercial 2.2 (Java)
Enigma SMTP and POP mail handler for transparent PGP email Ian Brown Enigma freeware 2.2 (Java)
WebFunds provides digital cash for browsers Systemics Ricardo free for non-commercial use 2.0 (Java)
Trader buy, sells and stores digital financial instruments Systemics N/A N/A 2.0 (Java)
Ricardo Issuer manages digital instruments (e.g., cash) Systemics Ricardo free for non-commercial use 1.16 (Perl)
The SOX Shop takes SOX money in exhange for goods, etc. Systemics Ricardo free for non-commercial use 1.1 (Perl)

Table 6: Applications using Cryptix

Others are in the pipeline. If you wish to add your application to the list, let us know.

Should my application supply Cryptix?

Probably, for these two reasons: Firstly, users in general don't have Cryptix on their machines, and you don't want separate detailed instructions that tell the user where to get it. Secondly, you need to guarantee that the right version is installed.

Where does Cryptix stop and applications start?

If the code is about strong crypto, and is generic in its applicability, then it can probably go in Cryptix. Cryptix doesn't and shouldn't really include any application code. By this, we mean that Cryptix is a developers tool, and is not intended to be useful directly for end-users.

These are some of the areas where we include developer library code that is a user of crypto:

Cryptix is evolving into a library of cryptographic tools and secure protocols.


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.

(Note that Cryptix-Java V2.2 does not use C or assembler, but V3.0 will. All releases of Cryptix-Perl use C.)

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 all of them but that is not really the issue ...

Hashes

In CAN-1, author Raif 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 a Faster Encrypt

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.


Copyright and License

Ownership

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

The Cryptix Development Team

Other contributors

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 proper 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, 1996, 1997 Systemics Ltd (http://www.systemics.com/) on behalf of the Cryptix Development Team (http://www.systemics.com/docs/cryptix/). 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://www.systemics.com/docs/cryptix/)

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.]

The Cryptix License - Pre V2.2

Releases of Cryptix-Java before V2.2 and Cryptix-Perl are covered by the following licence:

Copyright © 1995, 1996 Systemics Ltd (http://www.systemics.com/) 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, Systemics 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 Systemics Ltd (http://www.systemics.com/)

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.]


Cryptix Copyright © 1995-1997 Systemics Ltd
on behalf of the Cryptix Development Team.
All rights reserved.
Cryptix is a trademark of Systemics Ltd.