Cryptix Developers Team - FAQ

Revision is $Id: FAQ.html,v 1.13 1999/07/26 15:46:08 iang Exp $

Table of Contents

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


Description and Information

Introduction

The Cryptix Development Team develops and publishes new versions of Cryptix (primarily in Java, Perl is somewhat quiet).

Mailing List

A mailing list exists for the team. This list can be high volume. It is currently by invite only, as the original developers are protective of a private environment for the team. This could change. Mail the list maintainer for details.

Please don't post large source to this group. Send it to the intended recipient directly. As the state of the lists is such that individuals are keeping their own archives, sticking source in doesn't help.

Ian has set up a wonderful archive . No more humungous mailboxes !

Business Model

The team is a volunteer group. No funds are currently provided.

Support

Support for team activities is on an ad-hoc basis.

The Cryptix Homepage

Current Situation:

The Cryptix Homepage is a stalled at the moment. The important contents have been shifted to the distribution, and the Mirrors perform the normal functions of the homepage. Much of the old contents can be found in guide/cryptix.

We have the three cryptix.* domains. The issue is where and how to site them. One view is:

To mount these domains costs money and/or somebody willing to host them...

To Do

Mailgroups.


Source Access

Intro

Source is located in a Concurrent Version System (CVS) archive that is accessible over the net via Secure Shell (SSH).

Here is a good introduction to CVS. There are more resources listed below.

Access - Unix

Software Needed

You will need both SSH (I use 1.2.20) and CVS (I use 1.9.10, it needs to be at least client-server enabled) installed on your system. It should be working.

Creating a Key

In order to access the archive, create an SSH key:

    $ ssh-keygen
    Initializing random number generator...
    Generating p:  ........++ (distance 100)
        blah blah ...
    Enter file in which to save the key (/home/me/.ssh/identity): cryptix-cvs
    Enter passphrase:                  <<=== remember this bit
    Enter the same passphrase again: 
    Your identification has been saved in cryptix-cvs.
    Your public key is:
    1024 43 6425more numbers ...5623 me@crypto.hackers.com
    Your public key has been saved in cryptix-cvs.pub
    $ 

The public key is the long printed line of numbers terminating in your email address. It is also in the file cryptix-cvs.pub . Send this to the archive maintainer for adding into the CVS authorized_keys file. To avoid Mallory joining the party, send it PGP encrypted and signed.

Please don't use this key for any other access, create other keys for other purposes. See below for how to set up the key as a different name and wrap a script around it.

Environment

Next, add this to your environment:
    export CVSROOT=:ext:cryptix@helplets.com:/home/cryptix/cvsroot
    export CVS_RSH="/usr/local/bin/ssh"
in your .profile or equivalent. Notes:

Testing

Now, try the following:
    cvs get README
which will explain some archive details (not really written yet, still a test file). Once you get that file, you have proven access, so can go onto the next step, Usage, below.

Making SSH jump through hoops

You may need to convince SSH to do some special things like: To modify the SSH access from CVS is a little tricky. I wrote a script that pretended to be ssh, called ssh_helplets:
    #!/usr/local/bin/bash

    # set -x                                    # uncomment for debugging
    
    ssh_gateway="ssh gateway.org"               # set this to null if no gateway

    ssh_identity="-i .ssh/helplets"             # use this key only for helplets
                                                # identity file is at the gate

    exec ${ssh_gateway} ssh ${ssh_identity} $*
Then, I set the CVS_RSH (above) to call this program directly, and created the named key (above) on the firewall gateway.org (the files helplets* are located in the .ssh directory).

Once set up, when run, you should see something like (with set -x uncommented):

    me$ cvs get README
    + ssh_gateway=ssh gateway.org
    + ssh_identity=-i /home/me/.ssh/helplets
    + exec ssh gateway.org ssh -i /home/me/.ssh/helplets helplets.com -l cryptix cvs server
    Host key not found from the list of known hosts.
    Are you sure you want to continue connecting (yes/no)? yes
    Host 'helplets.com' added to the list of known hosts.
    cryptix's password: 
    Permission denied.
    cvs [checkout aborted]: end of file from server (consult above messages if any)
At which point it is time to send the new key.

Note that to setup an ssh through a gateway, you need account access to the gateway. SSH currently doesn't support proxy access directly, but it is being added.

Access - MS

Here are Ian's instructions for MS platforms based on his experiences with NT. They should work for W95. Please send any experiences to the list.

Software Needed

Download one of these.

Creating a Key

Execute SSH-keygen.exe to create a key pair. Mail the contents of the public key file (by default, identity.pub), PGP encrypted and signed, to archive maintainer

Once the archive maintainer has received your e-mail with your new SSH public key, he will add it to his list of authorised users and reply to your message. You should now be able to run CVS correctly. Try executing cvs get README to check everything is working correctly.

Environment

Set the following environment variables (using System Properties Environment under NT, or by putting an entry in your Win95 autoexec.bat):

Making SSH jump through hoops

Just as with Unix, it is possible to make SSH do tricks. In order to go through a proxy machine, assuming you cannot access the archive directly, you can point CVS_RSH to this batch file:
    @echo off
    ssh.exe -l login_name gateway.machine.com ssh -i .ssh/cryptix-cvs %1 %2 %3 %4 %5 %6
In this case, the first SSH will jump on to the gateway machine, and there, run another (Unix) SSH to connect to the repository.

Tips.

Some Notes

Some comments:

Usage

The entire hierarchy can be seen by browsing at http://helplets.com/java/cryptix-cvs/.

Here is a quick list of CVS commands:

The above commands should get you going, but be prepared to dive into the doco, see the resources below, when you want something beyond the basics. CVS is a big complex system, with many features and many traps for young players. That's another way of saying I haven't mastered it yet...

Resources

This is a list of resources on CVS.
+ An Introduction to CVS
+ USDA CVS site has these resources:
+ CVS tutorial
+ Cyclic are commercial supporters of CVS. They have an ftp repository .
+ The old (out of date) 1995 FAQ
+ OpenBSD's Anon CVS update page

Posting Progress

Unless your task is completely obscure or silly, it is customary to post intentions, progress and completion notes to the mailgroup. This is so that others can help, flag problems, discuss issues and methods, or consult with you if they need to get into that area.

Creating a New Repository

These notes are here because it's the logical place, rather than there being a need to create repositories often.

First thing is to make sure SSH and CVS are installed, as above. If these don't work, at least in client mode, then there is little hope for making a repository.

Next, make an account.

Next, set up an SSH directory and file with the authorized_keys in it of all the permitted accessors. An alternate way to do this is to leave off this file and distribute the password.

Finally, run the following command:

   cvs -d $PWD init
from within the account.

To access it, set up the CVS environment variables as described above.

There are more things you can do - set up chroot and only-cvs access, and make web archives, but I don't know how to do that yet.


Work In Progress

Current Active Projects

These are the current active projects.

Who Project Description Status
Twente SSH V2. Twente Uni team in full is Jeroen Edwin, Erwin old.
Sascha SSL V2 secure browser protocols, we need a snapshot release 2nd release ?
Jeroen IJCE IJCE to spec V1.2 WIP
Raif AES NIST page describes. live
LOKI'97, Serpent, Pentagon,
kit published
Paulo EC ElGamal over Elliptic Curves, Square (with Raif) Analysis
Ian (Quincy) Enigma secure mailer plugin for all mail handlers. Also looking at guerrilla groups and PFS published in Cj2.2, bug fixing, also in ByProxy.
Edwin PGP produce complete compatible PGP in Java - JCE then OP. WIP
Erwin WebFunds see webfunds.org. works, distributes. Needs OpenPGP

Table 1: Current active projects

Wish List

We want everything ... well, almost. Here's a current list of wants, there may be others: Opinions may differ.

Next Major Release

See the mirror site for the last major release.

The major release will be 3.0.4. It might include:


Distribution

These are working notes. I have produced about 4 distributions this way, so I'm getting closer to the truth. We are still prototyping though.

Introduction

How CVS wants to see it

CVS works on the basis of tags which are an advancement on other source code control system that rely on simply dates and version or release numbers (CVS includes this as well).

Tags are alphanumeric labels for a bunch of source files. A tag can only refer to a single version of a source file at once, so when you specify a tag, you get a distribution of the source according to how the tag is currently set. There are several sorts of tags:

CVS wants us to create a distribution by tagging each file version that is in the distribution. That's what we talk about further below.

Goals of the Distribution System

We have a number of primary goals in building a release system: There's also a number of secondary goals - ones that I might sacrifice just to get the ball rolling:

Overview of System

All the above considerations leads me to the following rough architecture:

From CVS itself, only do source releases. Then, within the source release, provide the tools (such as the src/build/*.sh scripts) to build the binary distributions.

In order to do the source distribution, all source that has to go in there has to be tagged with the distribution tag. This is a manual task of some tedium (see util/dist_tag.sh) This makes sense in that any distribution requires a lot of difficult questions as to what goes in and what is omitted. Each decision is instantiated by applying the distribution tag to each file, meaning that it is chosen for inclusion.

Nota bene that it is the distribution maintainer's job to do this, not the programmers'. The distribution will have a whole bunch of test scripts and so forth that will bounce if not done properly. When programmers wishes to add something into the distribution, they should coordinate with the maintainer on this.

Then, when files are tagged, do a new

   cvs get -r Cryptix_1-2-3 current
The files in this tree will be sticky to 1.2.3, so the process is one of testing, fixing files, changing the tags on fixed files, and then updating this tree.

A script in the source can produce a source release (see util/dist_source.sh) or the whole release (see util/dist_all.sh). This latter script produces a source release, unpacks it, and produces the binary from that.

A script in the CVS source should produce a source release, which should itself be capable of producing a binary distribution. This binary should be produced from the source release, and then extracted into a temporary directory. There, run the tests. As problems arise, fix the files, and make a new distribution. As fixes work, they need to be tagged with the distribution tag.

When the entire cycle is error-free, and the set of files (actually, revisions) to distribute is tagged, throw away all the above, and do a new

    cvs export -r Cryptix_1-2-3 current

And then run through the process again. The test results duplicate the previous results (this hasn't been tried to date).

Then copy the source zip and other (binary or docs) zips to the archive, and announce the new distribution.

Tagging

The first step is to decide on the distribution tag. For sake of argument, we assume here it is an increment on the previous one, and that makes it Cryptix_1-2-3.

Then, in a hierarchy, go through the laborious process of tagging each file and module with that tag. Technically this is done with:

   cvs tag Cryptix_1-2-3 [files...]
It's probably worth doing this at least once manually, just to get the feel of the distribution. Notes:

Building the Distribution

An important first point is to decide what is in the distribution. These are decided by the files util/man/source.man and util/man/binary.man. They should be adjusted to include new source and its unit tests. Then they should be retagged.

Once everything is tagged, extract a new CVS directory:

    mkdir 345
    cd 345
    cvs get -r Cryptix_3-4-5 current

Then, the process is one of checking the contents, running the script:

    cd current
    util/dist_all.sh
checking again, and rerunning the script.

Once the distribution gets to the end, and all tests pass, add the -export flag (which is only locally set up, this part will need rewriting) to export the distributions up to the web server.

See the util index for more information on the scripts.

Some points to make:

Adding Your Code

To get a new unit added into the distribution, mail the distribution team. asking for the unit to be added in, and include:

That first requirement, the name of the unit test(s) is paramount. With that, it is possible to determine the rest. Without that, the addition will take twice or three times as long, as the test will have to be written or cobbled together. This would generally push the addition down in the priorities.

Some Other Comments

Build and distribution is a core skill for the team to develop, and it is fair to say that we haven't really done much in this area. To help us, here are some docs that comment on the subject.

Programming Standards

Security

I suspect this is something of an open ended section.

Baltimore makes an interesting claim:

  Note: Any serious Java implementation of cryptographic functionality
  must include a mechanism for obfuscating sensitive information, such as
  keys, in memory. This will inevitably slow down the operation of the
  toolkit.

David:

This is a hard problem in Java (or any garbage-collected language). Obfuscating the keys isn't enough, because there will still be any number of copies of data derived from the keys in memory. That's especially true for the public key algorithms using java.math.BigInteger, since there is no way to wipe intermediate results; you just have to rely on them being garbage collected.

I remember seeing a hack for Linux posted to a newsgroup (comp.security.unix?) showing how to disable virtual memory for an particular program - the example was PGP 2.6.x. It required installing the program suid root, and patching it to make a kernel call (mlockall(), IIRC) then drop privileges.

Installing the java interpreter suid root is a definite no-no for obvious reasons, but maybe we could provide a native C wrapper for Linux that would call it. The newsgroup discussion implied that it was possible to do a similar thing for Windows NT (but not 95 :-( ).

Getting the Best out of Cryptix

The benefit of strong crypto is best achieved by a balance of code, documentation and testing, as this allows the best use of limited resources.

        power(Cryptix)  = constant * code * doco * tests

Cryptix is now an internationally-used strong crypto package. Now that many people are using the product, it is important that each distribution not generate work for us by causing users to ask obvious questions, trip up on silly bugs, or grumble about the product because there are bits missing.

There are several aspects to the overall process of producing quality code:

Which of Grandma's eggs you wish to suck is dependent on the moment!

Unit Tests

Testing is no longer a nicety in Cryptix, it's a necessity. Cryptix has grown to the point where it can no longer be tested manually, by just running a bunch of programs and looking at the results. During distribution, each part of Cryptix is tested (sometimes multiple times) to prove that it is good.

The objective of the distribution testing is to eliminate errors in the distribution phase. It cannot eliminate coding errors, and it can't improve the basic product.

Without automated testing, the complexity and size of the product is such that there will be sufficient errors in every distribution such as to make it unusable. So in a sense, the objective can be read as re-making Cryptix usable for the users.

To meet the objective, the distribution scripts needs to prove that each part of Cryptix is present and working. This is done by running the unit tests which are, literally, tests of component units of the whole.

The main feature of these tests is that they provide a positive indication that the code is present, and that it is working.

A unit test should conform to the following:

Once the unit test is ready, send the class name entry point to the distribution team.

In fact, sending in the test is the most important thing that should be done, if the issue is getting the code into the distribution. From the test, it is fairly easy to work out what code is required. Without the test, the distributor needs to look for the test, which is fraught with errors, or to write a test, which is inefficient.

Native Testing

This has not yet been tried at the distribution level. The testing of native code currently borrows from the existing algorithm unit tests, which leaves a number of shortfalls as implied below.

Unit testing of native code will need to ensure that

One possibility is to run each unit test twice, once for native, once for java. This could be done simply by including different entry points into the tests:
    java cryptix.test.TestLOKI91.native
    java cryptix.test.TestLOKI91.java

Another possibility is that the unit tests could be upgraded to cope.

This is not a big issue in advance, the most important step is to get running native code on the distribution platforms (Unix) so that the strategy can be worked out.

Exit Codes

A test should exit according to the conventions in Table 2, which are interpreted by distribution scripts.

  no failures failures
no successes no tests = 3 bad = 1
successes good = 0 carry on = 4

Table 2: Matrix of Test Exit Codes

The purpose of the mixed-results exit code 4 is to allow the distribution scripts to carry on and test the entire set of tests, without forcing a debugging phase for each single bug found. It's a problem of efficiency, as normally found in compilers' reporting of errors and so forth.

If the carry on result cannot be provided, then bad indication of 1 should be returned.

In Java, to return the code, call System.exit(n) where n is the exit code desired.

Documentation

Any documentation and testing that you can supply will be immensely appreciated by the users.

Documentation can defer questions being asked over and over again on the mail groups. By making the job of the user easier, we make the amount of support less and can spend more time on new code.

There are several ways you can do this:

Everybody is encouraged to work together on updating the documentation; please be careful about preserving other people's literary achievements.

Applets

There are problems with some browsers (I.E. and HotJava) if using Cryptix from applets. Some of the examples allow arbitrary files to be read or written. To combat this:

Historical note: there may be more problems using Cryptix from applets, as Cryptix was never intended to be used by applets.

Whitespace

Our working white space convention is:

In the source release there is a Java application called util.FixLineEndings that can be used to convert tabs to spaces, and line endings to any format. Make sure that the root of the source release is on the CLASSPATH, then do "java util.FixLineEndings" to get a summary of options.

There are also shell scripts to convert the whole source tree at once. For example:

sh util/unixify.sh
or
sh util/dosify.sh

CVS should probably deal with CRs. Iang's guess at this stage (not having tried it) is to strip out CRs on input, and add them in on output (only for Windows users). This is a known problem for which there are known fixes.

Final Keyword

Fields should be final iff they are constants.

Classes should usually be non-final, unless they need to be final for security (example: cryptix.provider.cipher.*).

Methods should usually be non-final, unless

  > It speeds things up, and may prevent security holes where
  > people extend our classes deviously, but is it appropriate
  > in a library?

Static and private methods are called using static binding, so they are just as efficient as final methods (the 'final' qualifier is redundant for these methods, although there are quite a few cases in Cryptix where it is there anyway). In the cipher and md classes, almost all of the methods that need to be called quickly are already private.

File Name Conventions


Politics, Culture, etc

This entire section is rantings by iang who is probably not of the same opinion as anyone else...

How is the team organised?

Organised? Not very.

In political terms, we are a socialist taskocracy or somesuch. That is, power is shared amongst those who do the work. Hacker power rules.

This effectively means that those who make the distributions say what goes in them. Those who write a particular interface have final say as to how it is done.

Those who write original code get to say how it is done. By doing it. But they don't get any rights in later versions, as later editors have the same rights.

The counterbalancing to this tremendous concentration of power in the hands of the do-ers is the ability of the rest of the world to ignore, rewrite or fix anything they do not like. Ignorance is the privilege of the market, and a message for the developer; rewriting or fixing converts critics into do-ers.

All this leads to several effects:

There is an well-written paper by Eric S. Raymond called The Cathedral and the Bazaar that more or less agrees with this viewpoint. (However, it more or less disagrees with the following "by invitation" approach).

Another description is the chapter on "The Rise of ``Worse is Better''" in an article on Lisp history by Richard P. Gabriel. But this probably goes in a general software engineering section.

Why is the team "by invitation?"

Here is a mostly unedited mail describing the viewpoint of iang :

I think there are a lot of issues, which add up in my experience to a conclusion that I think the group will work better if it is managed as an "invite-only" club.

I am not sure what all these things are, but I'll have a go at it:

Industrial Espionage: yes, that's a concern. Whilst pure competition doesn't count, there is plenty that an aggressive producer of crypto could do to the group to kill it if the name of the game was to cause Cryptix to wither and die. If I was Baltimore, I could have a lot of fun. Even if I was Sun, I would have a lot of ability to influence the fate of the team if I could see everything that was going on in it.

Team Size: there is an issue here in managing the amount of activity. Whilst it is good to have lots of code happening, there is lots of support that needs doing. At the moment, things are quiet, but over the period of the release, many man-weeks were consumed in support activities (femme-weeks can be included at premium rate here :))

If the team gets much more productive (that is, releases start happening more quickly), then there is going to be a need to boost up all the support side. That means things like the CVS and automatic distribution scripts. Now, these are not technically out of our reach, but someone has to do all the work. We have talked about it in the past, but it is no exaggeration to say that the non-coding aspects of Cryptix can be extremely costly as well as boring.

Noise level: with a team of this nature, it is important to keep everything focused. If we have non-coders, or inactive people, that are not focused on writing code, then there is a temptation for them to get involved and waste other people's time. It's bad enough when we disagree amongst ourselves, but at least we are all relatively quick to work out when the code is suffering and make some sort of judgement as to whether a discussion is still valuable.

So my current viewpoint is to keep my eye out for people that are producing hot crypto and to try and make sure that they are willing active contributors. For e.g., there was a company that wanted to join, but as far as I could see they were going to keep their efforts proprietary and just incorporate the Cryptix bits were there were gaps.

This is a working policy, not dogmatic truth. It's a combination of logic, experience and paranoia. So, comments eagerly sought.

In particular, I am thinking about The Cathedral and the Bazaar which says we should open up.

How can I help someone into the team?

If you know of a person that wishes to "get involved" then try this strategy:

Culture

Nope, no culture yet. Give it another thousand years and some yeast and hops.

A Rant on the License

Follows is another slightly dynamic rant by iang:

        The goal of the Cryptix license is to efficiently
        allow freeware crypto to be published.

The license does not change the ownership of the code, that remains vested in the original owner. So, if your University applies the rule that all student works are owned by the University (as many do), then this is no problem as the University can be stated as such: the owner of the code. Although we might want to better reflect that distinction in the FAQ, which is where it is currently preferred to list such issues, once, in full.

The Cryptix license also has no effect on the authorship of the code. The current method is to put the author in the @author tag, as code is written and changed.

What the license does do is assert copyright on behalf of the owners (not the authors, I guess), and it names them as the Cryptix Development Team. This then becomes a device for protecting the code against attacks. It is also generic and common, which means that we save a lot of hassle in distribution time: one notice throughout the system means ease of packaging and ease of understanding by readers.

The motive for using Systemics as the asserter or claimor of the rights (on behalf of...) has changed over time. Originally Systemics wrote the code, so it was obvious.

Now, Systemics doesn't write (much of) the code, and doesn't wish to (much). But there is some value to the group in maintaining a corporate umbrella over the product. Copyright is normally asserted by corporations and not individuals for the simple reason of limited liability. That is, if one of the PGP packets goes astray on the way to NASA's latest launch and the bright new space station decides its geosync orbit is just north of the Empire State building, then some questions are going to be asked...

In this case, Systemics makes a useful protective device for the individuals. Basically, when the squillion-dollar lawsuit lands, Systemics goes under, all assets sunk, and we all move onto fat talking engagements about how we sunk the space station. I am somewhat flippant about this because a. it's unlikely, and b. it's a risk of business, and c. I have dealing with companies of this nature for years. It's also worth noting that companies and lawyers know what is going on. The game is familiar to all.

There are other considerations.

Of course this comes at a cost. I gather the DebIan (sp?) crowd of Linux hackers have recently incorporated (I suppose for these reasons) and it has cost them a couple of thousand dollars. Which they don't have, donations kindly accepted :))

There is also a risk to Systemics that the boys at no such agency will phone up the regulators and put the squeeze on. Fine, Cryptix ends up squeezed all over the net, and Systemics a. folds, or b. disowns it.

The current benefits to Systemics are of course some useful kudos, and some possibility of picking up consulting work. As far as collected revenues go they have not been worth squabbling over so far :-/ but the future holds more potential. Indeed, with recent activity, there is a plausible upside for Systemics, as there is for the team.

However, it is an open market. Any member of the team is free to sell software or consulting or work based on Cryptix; the license ensures that everyone has at least an equal chance of doing well. So Systemics has to maintain a fair balance, else risk breaking up the team.


Team-FAQ History

$Log: FAQ.html,v $ Revision 1.13 1999/07/26 15:46:08 iang elimination of old systemics.com domains, emails, etc. Revision 1.12 1999/03/05 19:18:40 gelderen
  • added putty. Revision 1.11 1999/03/02 20:55:13 gelderen
  • added SSH comment Revision 1.10 1998/06/01 19:33:53 iang
    • updated the unix ssh cvs access notes
    Revision 1.9 1998/04/26 18:58:19 iang
    • formatting of revisions (again).
    Revision 1.8 1998/04/26 18:56:20 iang
    • Oops, previous was correct, the cryptx repository is odd, not the FAQ.
    Revision 1.7 1998/04/26 11:39:21 iang
    • dropped cvsroot from home in ssh line for cvs access. wrong.
    Revision 1.6 1998/02/17 20:55:05 iang
    • correction to Edwin's name
    Revision 1.5 1998/02/15 17:56:32 iang
    • fixed silly comment
    • actually, the new members were added to the project list.
    Revision 1.4 1998/02/15 17:53:58 iang
    • zox address wrong
    Revision 1.3 1998/02/15 17:52:43 iang
    • added updates
    Revision 1.2 1998/01/31 23:38:31 iang
    • moved from ../cryptix/team-FAQ.html
    • not at later version, needs to jump to 1.15 or later
    Revision 1.11 1998/01/12 21:50:52 hopwood
    • Moved history to end of file.
    • Fixed some typos, cosmetics.
    Revision 1.10 1998/01/11 23:59:00 iang Revision 1.9 1998/01/11 17:01:59 iang Revision 1.8 1998/01/09 22:34:34 iang Revision 1.7 1998/01/06 20:14:24 iang
    • team-FAQ: updated to review distribution current practice
    • Support: a few updates from post
    • Compilation: ?
    Revision 1.6 1998/01/02 21:43:52 iang
    • updated current projects
    Revision 1.5 1998/01/02 21:31:16 iang
    • added reference to NIST quest
    Revision 1.4 1997/12/30 01:26:19 iang
    • added refs for maths algorithms in HB/AC Menezes to wish list
    Revision 1.3 1997/12/23 19:20:17 iang
    • press release finished off, as published, mostly
    Revision 1.2 1997/12/23 15:31:41 iang
    • Copied in my working team FAQ to this location, which is at least visible.
    • Many Many Changes, this one was well out of date.

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