NetBSD

History

tls 4147a3c54a Add new Makefile knob, USE_FORT, which extends USE_SSP by turning on the FORTIFY_SOURCE feature of libssp, thus checking the size of arguments to various string and memory copy and set functions (as well as a few system calls and other miscellany) where known at function entry. RedHat has evidently built all "core system packages" with this option for some time. This option should be used at the top of Makefiles (or Makefile.inc where this is used for subdirectories) but after any setting of LIB. This is only useful for userland code, and cannot be used in libc or in any code which includes the libc internals, because it overrides certain libc functions with macros. Some effort has been made to make USE_FORT=yes work correctly for a full-system build by having the bsd.sys.mk logic disable the feature where it should not be used (libc, libssp iteself, the kernel) but no attempt has been made to build the entire system with USE_FORT and doing so will doubtless expose numerous bugs and misfeatures. Adjust the system build so that all programs and libraries that are setuid, directly handle network data (including serial comm data), perform authentication, or appear likely to have (or have a history of having) data-driven bugs (e.g. file(1)) are built with USE_FORT=yes by default, with the exception of libc, which cannot use USE_FORT and thus uses only USE_SSP by default. Tested on i386 with no ill results; USE_FORT=no per-directory or in a system build will disable if desired.		2007-05-28 12:06:17 +00:00
..
COPYRIGHT
des_locl.h
des_modes.7
des_modes.pod
des_ver.h
des.3	fix the man page.	2006-03-20 21:33:26 +00:00
des.h	Nobody should be using des_ks_struct (Jukka Salmi)	2006-03-20 21:31:08 +00:00
des.pod
FILES0
INSTALL
KERBEROS
Makefile	Add new Makefile knob, USE_FORT, which extends USE_SSP by turning on the	2007-05-28 12:06:17 +00:00
ocbc_cksm.c
ocbc_enc.c
ocfb64ede.c
ocfb64enc.c
ocfb_enc.c
odes_enc.c
oecb3_enc.c
oecb_enc.c
oede_cbcm_enc.c
oenc_read.c
oenc_writ.c
ofcrypt_b.c
ofcrypt.c
oncbc_enc.c
oofb64ede.c
oofb64enc.c
oofb_enc.c
opcbc_enc.c
options.txt
oqud_cksm.c
orand_key.c
oread2pwd.c
oread_pwd.c
ornd_keys.c
orpc_enc.c
oset_key.c
ostr2key.c
oxcbc_enc.c
README
rpc_des.h
shlib_version
spr.h
VERSION

README

		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)