the secret key before we've encrypted it and using the right NID for RC2-64.
Add various arguments to the experimental programs 'dec' and 'enc' to make
testing less painful.

This stuff has now been tested against Netscape Messenger and it can encrypt
and decrypt S/MIME messages with RC2 (128, 64 and 40 bit) DES and triple DES.

Its still experimental though...

(meaning pointer to char) to des_cblock * (meaning pointer to
array with 8 char elements), which allows the compiler to
do more typechecking.  (The changed argument types were of type
des_cblock * back in SSLeay, and a lot of ugly casts were
used then to turn them into pointers to elements; but it can be
done without those casts.)

Introduce new type const_des_cblock -- before, the pointers rather
than the elements pointed to were declared const, and for
some reason gcc did not complain about this (but some other
compilers did).

which cost me some time to find out about.

find the right RecipientInfo based on the recipient certificate (so would
fail a lot of the time) and fixup cipher structures to correctly (maybe)
modify the AlgorithmIdentifiers.  Largely untested at present... this will be
fixed in due course. Well the stuff was broken to begin with so if its broken
now then you haven't lost anything :-)

unsigned/signed cmp error in asn1parse. Change various pem_all.c args to
use pem_password_cb.

use (certain parts of) OpenSSL.

Submitted by: Oleg Girko

that's what the calling code seems to expect.

integers was completely broken. Also added a NEG_PUBKEY_BUG compilation option
to compensate for public keys improperly encoded as negative integers.

thread-safe (where thread-safe counterparts are not available on all
platforms), and don't memcpy to NULL-pointers
Submitted by: Anonymous
Reviewed by: Bodo Moeller

Also, clean up htons vs. ntohs confusions.

Submitted by:
Reviewed by:
PR:

those functions without having a parameter list declaration.
(There are various similar cases left ...)

one for those functions (is it?).

place to look for them.

instead I've picked "enc", because that's what's in the prototypes.
("_encrypt" is reserved only as an external name, but still
using it in an application doesn't look like good style to me --
and it certainly isn't if the point is just avoiding shadowing,
which is apparently why the previous name "encrypt" was changed.)