returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.
that can automatically determine the type of a DER encoded
"traditional" format private key and change some of the
d2i functions to use it instead of requiring the application
to work out the key type.
Never use des_set_key (it depends on the global variable des_check_key),
but usually des_set_key_unchecked.
Only destest.c bothered to look at the return values of des_set_key,
but it did not set des_check_key -- if it had done so,
most checks would have failed because of wrong parity and
because of weak keys.
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
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).
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 :-)
