Remove some outdated README files, to avoid confusing people.

This is an OpenSSL-compatible version of AES (also called Rijndael).

aes_core.c is basically the same as rijndael-alg-fst.c but with an

API that looks like the rest of the OpenSSL symmetric cipher suite.

This is a quick packaging up of my blowfish code into a library.

It has been lifted from SSLeay.

The copyright notices seem a little harsh because I have not spent the

time to rewrite the conditions from the normal SSLeay ones.

Basically if you just want to play with the library, not a problem.

eric 15-Apr-1997

Configuration modules. These are a set of modules which can perform

various configuration functions.

Currently the routines should be called at most once when an application

starts up: that is before it starts any threads.

The routines read a configuration file set up like this:

-----

#default section

openssl_conf=init_section

[init_section]

module1=value1

#Second instance of module1

module1.1=valueX

module2=value2

module3=dso_literal

module4=dso_section

[dso_section]

path=/some/path/to/some/dso.so

other_stuff=other_value

----

When this file is loaded a configuration module with the specified string

(module* in the above example) is looked up and its init function called as:

int conf_init_func(CONF_IMODULE *md, CONF *cnf);

The function can then take whatever action is appropriate, for example further

lookups based on the value. Multiple instances of the same config module can be

loaded.

When the application closes down the modules are cleaned up by calling an

optional finish function:

void conf_finish_func(CONF_IMODULE *md);

The finish functions are called in reverse order: that is the last module

loaded is the first one cleaned up.

If no module exists with a given name then an attempt is made to load a DSO

with the supplied name. This might mean that "module3" attempts to load a DSO

called libmodule3.so or module3.dll for example. An explicit DSO name can be

given by including a separate section as in the module4 example above.

The DSO is expected to at least contain an initialization function:

int OPENSSL_init(CONF_IMODULE *md, CONF *cnf);

and may also include a finish function:

void OPENSSL_finish(CONF_IMODULE *md);

Static modules can also be added using,

int CONF_module_add(char *name, dso_mod_init_func *ifunc, dso_mod_finish_func

*ffunc);

where "name" is the name in the configuration file this function corresponds

to.

A set of builtin modules (currently only an ASN1 non functional test module)

can be added by calling OPENSSL_load_builtin_modules(). 

The function OPENSSL_config() is intended as a simple configuration function

that any application can call to perform various default configuration tasks.

It uses the file openssl.cnf in the usual locations.

		libdes, Version 4.01 10-Jan-97

		Copyright (c) 1997, Eric Young

			  All rights reserved.

    This program is free software; you can redistribute it and/or modify

    it under the terms specified in COPYRIGHT.

--

The primary ftp site for this library is

ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/libdes-x.xx.tar.gz

libdes is now also shipped with SSLeay.  Primary ftp site of

ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-x.x.x.tar.gz

The best way to build this library is to build it as part of SSLeay.

This kit builds a DES encryption library and a DES encryption program.

It supports ecb, cbc, ofb, cfb, triple ecb, triple cbc, triple ofb,

triple cfb, desx, and MIT's pcbc encryption modes and also has a fast

implementation of crypt(3).

It contains support routines to read keys from a terminal,

generate a random key, generate a key from an arbitrary length string,

read/write encrypted data from/to a file descriptor.

The implementation was written so as to conform with the manual entry

for the des_crypt(3) library routines from MIT's project Athena.

destest should be run after compilation to test the des routines.

rpw should be run after compilation to test the read password routines.

The des program is a replacement for the sun des command.  I believe it

conforms to the sun version.

The Imakefile is setup for use in the kerberos distribution.

These routines are best compiled with gcc or any other good

optimising compiler.

Just turn you optimiser up to the highest settings and run destest

after the build to make sure everything works.

I believe these routines are close to the fastest and most portable DES

routines that use small lookup tables (4.5k) that are publicly available.

The fcrypt routine is faster than ufc's fcrypt (when compiling with

gcc2 -O2) on the sparc 2 (1410 vs 1270) but is not so good on other machines

(on a sun3/260 168 vs 336).  It is a function of CPU on chip cache size.

[ 10-Jan-97 and a function of an incorrect speed testing program in

  ufc which gave much better test figures that reality ].

It is worth noting that on sparc and Alpha CPUs, performance of the DES

library can vary by upto %10 due to the positioning of files after application

linkage.

Eric Young (eay@cryptsoft.com)

The stuff in here is based on patches supplied to me by

Steven Schoch <schoch@sheba.arc.nasa.gov> to do DSS.

I have since modified a them a little but a debt of gratitude

is due for doing the initial work.