提交 0f957287 编写于 作者: R Rich Salz

Remove some outdated README files, to avoid confusing people.

Reviewed-by: NAndy Polyakov <appro@openssl.org>
上级 457f7b14
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.
RIPEMD-160
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
This is my implementation of RIPEMD-160. The pentium assember is a little
off the pace since I only get 1050 cycles, while the best is 1013.
I have a few ideas for how to get another 20 or so cycles, but at
this point I will not bother right now. I believe the trick will be
to remove my 'copy X array onto stack' until inside the RIP1() finctions the
first time round. To do this I need another register and will only have one
temporary one. A bit tricky.... I can also cleanup the saving of the 5 words
after the first half of the calculation. I should read the original
value, add then write. Currently I just save the new and read the origioal.
I then read both at the end. Bad.
eric (20-Jan-1998)
Mutithreading testing area.
Since this stuff is very very platorm specific, this is not part of the
normal build. Have a read of doc/threads.doc.
mttest will do some testing and will currently build under Windows NT/95,
Solaris and Linux. The IRIX stuff is not finished.
I have tested this program on a 12 CPU ultra sparc box (solaris 2.5.1)
and things seem to work ok.
The Linux pthreads package can be retrieved from
http://www.mit.edu:8001/people/proven/pthreads.html
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册