Commit Graph

7 Commits

Author SHA1 Message Date
dd
7894e59b7f Nuke unused variables. 2001-06-24 23:41:57 +00:00
markm
4dfdc66cab Use libcrypto instead of libdes. 2000-02-24 21:10:28 +00:00
peter
efabb9ccb1 $Id$ -> $FreeBSD$ 1999-08-28 01:35:59 +00:00
wpaul
71a9e7d996 Apply patch from Stefan Esser to close PR #7941: add code to handle
dynamic loading of libdes on ELF systems. The patch looks correct to
me.
1998-09-16 01:50:04 +00:00
charnier
a816a4029a Use err(3). Put includes in alphabetical order.
Rewrote man page in mdoc format.
Document -v and -p flags.
1997-09-23 06:36:27 +00:00
wpaul
8a67f91ff9 Work around a bug (deficiency?) in the libdes Secure RPC compat interface.
The way Secure RPC is set up, the ecb_crypt() routine is expected to
be able to encrypt a buffer of any size up to 8192 bytes. However, the
des_ecb_encrypt() routine in libdes only encrypts 8 bytes (64 bits) at a
time. The rpc_enc.c module should compensate for this by calling
des_ecb_encrypt() repeatedly until it has encrypted the entire supplied
buffer, but it does not do this.

As a workaround, keyserv now handles this itself: if we're using DES
encryption, and the caller requested ECB mode, keyserv will do the right
thing.

Also changed all references to 'rc4' into 'arcfour' just in case some
litigious bastard from RSA is watching.

Note that I discovered and fixed this problem while trying to get
a part of NIS+ working: rpc.nisd signs directory objects with a 16-byte
MD5 digest that is encrypted with ecb_crypt(). Previously, only the
first 8 bytes of the digest were being properly encrypted, which caused
the Sun nis_cachemgr to reject the signatures as invalid. I failed to
notice this before since Secure RPC usually never has to encrypt more
than 8 bytes of data during normal operations.
1997-06-17 18:03:52 +00:00
wpaul
7467e74fd1 This commit was generated by cvs2svn to compensate for changes in r26234,
which included commits to RCS files with non-trunk default branches.
1997-05-28 15:44:22 +00:00