![]() |
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 |
$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.
Return to the Cryptix Index. Headings below return to the above table of contents.
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.")
To download source or binaries, start at the Cryptix Mirror Index. We are actively looking for more mirror sites.
Mailing lists exist for the users of Cryptix. Here are the terms:
subscribe cryptix-java subscribe cryptix-perlto majordomo@systemics.com.
Do this by sending
subscribe cryptix-java my_name@cypher.comas above. The list maintainer will need to authorise this.
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.
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.shReplace 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\makedocsYou will need a reasonable amount of free memory to do this (about 12 MB).
As above, but the "makedocs" script is in the doc/ directory.
All the documentation is injavadoc
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 tojavadoc
, which will producedoc/packages.html
which is a browsable file.
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:
sh util/finalbuild.sh
util\finalbuild
Also see the compilation guide.
To compile the native library source, see the file native/README.txt.
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.
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.
$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 iangRevision 1.8 1997/12/19 06:32:33 hopwood
- merged below my compatibility sections, needs review, should perhaps be taken out and put in another separate file.
Revision 1.7.1 1997/12/18 hopwood
- Committed changes below.
Revision 1.7 1997/12/18 12:03:51 iang
- Merged with my version, and fixed conflicts.
- Win32 native libraries have been tested.
- Cryptix 3.x has now been tested with JDK 1.0.2 and Netscape 4.0.4.
- Compatibility sections reorganised.
- Additions to History section for V3.
Revision 1.6 1997/12/18 10:18:17 iang
- mods to refer FAQ to mirror index
Revision 1.5 1997/12/14 05:40:36 iang
- minor comments on the 'extra crypto'
Revision 1.4 1997/12/14 05:28:41 iang
- minor link problem, and title mismatch
Revision 1.3 1997/12/07 06:47:07 hopwood
- Reviewed FAQ for V3. Adopted internal FAQ as model, rather than external.
- Added history and dropped references to 2.4.x.
- Rewrote IJCE section. Needs review.
- Split old General into Team and Ref sections.
- Reworked header and trailer to new style, added image.
- Many minor changes, more review needed.
Revision 1.2 1997/12/07 06:44:08 hopwood
- Fixed problem that was causing history changes not to show up.
Revision 0.1.22 1997/11/18 Revision 0.1.21 1997/10/30
- Merged version of FAQ in source release with version on www.systemics.com.
Revision 0.1.20 1997/10/30
- Spelling mistakes, added caveat to owners list after help-spammer.
Revision 0.1.19.1 1997/10/29
- Separated bugs into - features - java - perl.
- Reviewed the IJCE comments, update to reflect current.
- General quick review.
Revision 0.1.19 1997/10/14
- Added to the list of copyright owners, and split the list into Cryptix Development Team members, and external contributors.
- Added a section describing How to Compile the Source Release (for Cryptix-Java 2.2.2 and later).
- Updated Use of Native Code section, to reflect the fact that native linking now works in release 2.2.2.
- Updated the section about Java 1.1.
- Merged David Hopwood's version of the FAQ for Cryptix 2.2.2 with the version on www.systemics.com.
- Added an authoritative URL for this FAQ.
Revision 0.1.18 1997/10/14
- Editing of CAN-4 - lots of comments need to be sorted out.
- FAQ had a test license in for RPK - now dropped - shouldn't have been there.
Revision 0.1.17 1997/10/11
- Added CAN-4.html - straight from Raif (but second send, I lost the first).
Revision 0.1.16 1997/09/23
- Added "The Advantage of Source Availability".
Revision 0.1.15 1997/09/18
- More JCE implementations.
Revision 0.1.14 1997/09/16
- Added WP's JCE and SSL.
Revision 0.1.13 1997/09/10
- Added Ajo Passon's article reference. Fame and Fortune at last :-)
Revision 0.1.12 1997/09/09
- Added more sources of Java crypto (all quite specific, free, small)
Revision 0.1.11 1997/09/08
- Added pegwit to More...
Revision 0.1.10 1997/09/06
- Added Modultek to applications table, fiddled with table a little.
Revision 0.1.9 1997/08/27
- Added a little to 'More Java Crypto', nothing worth looking at though.
Revision 0.1.8 1997/08/26
- Added JSafe link + prices :-)
Revision 0.1.7 1997/08/25
- Added Date at top.
- Added History record from CVS.
No, Cryptix is available from servers located around the world.
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.
No, we use our own implementation of the RSA algorithm.
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.
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.
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.
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.
Why don't the Cryptix-Java classes implement the Serializable interface?
There are a number of reasons. Here's David's list:
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.
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.]
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 ...
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.
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.
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).
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 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.
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.
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.
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.
Future versions may drop support for Java 1.0.2, so you should plan to move to Java 1.1 soon.
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!
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.
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.
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.
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.
RSA buys Baltimore J/Crypto and renames it as JSafe with prices starting at $15,000. The provider comes with Ron's normal algorithms plus SHA and DES.
Includes two examples:
Uh, it would be immoral and highly naughty of us to tell you. But here are a few "facts":
Armed with the above pseudo-facts, there are some things you can do to check out the situation:
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.
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 fast newish RC2 ? ? new RC4 ? ? new SAFER ? ? new Square ? ? very new Table 5: Vitally Secret Statistics
Notice the studied absence of a recommendation from the team :))
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:
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.
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
"SHA" can be used as an alias for "SHA-1".MessageDigest.getInstance("SHA-1")
, or
MessageDigest.getInstance("SHA-0")
.
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).
Sorted with most recent first.
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.
> 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.
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.
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 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.
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 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
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.
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.
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 ) );
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).
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).
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.
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.
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:
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 ...
In CAN-1, author Raif Naffah compares the speed of several hash functions.
In detail, CAN-2 compares the speed of several symmetric block ciphers.
To do.
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.
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.
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.
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:
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.]
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:
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.]