Cryptix README or Readme Src or Readme Bin
Frequently Asked Questions
API index
Documentation
Copyright and License
Description and Information | Installation | "Regulations" and Patents | Implementation Choices | Compatibility Issues | Strength, Reliability, Etc. | Performance | Known Bugs | Copyright and License | Cryptix

Development

Team

Cryptix TM
Frequently Asked Questions

$Revision: 1.49 $
$Date: 1999/08/01 04:39:51 $

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

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; The Perl version is no longer maintained and this FAQ concentrates on the Java version.

Where to get Cryptix

To download source or binaries, start at the Cryptix Mirror Index. We are actively looking for more mirror sites, preferrably in Australia and South America.

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 available at the time..

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

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:

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:

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 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 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 [1] Yes [1] Yes [1]
2.2.0a and 2.2.1 No Yes No No
3.0 - 3.0.3 No [2] Yes No [5] No [3]
3.1.x onward Not tested Yes Yes Not tested

Notes:

Table 5: Java version requirements

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

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

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

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

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

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:

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

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


Known Bugs

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:

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.

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:

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

Inactive members include:

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


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