(Latin for "comments", anyone?)

DES's keyschedules.

I know these two should be separate, and I'll back out the DES changes if they
are deemed to be an error.

Note that there is a memory leak lurking in SSL somewhere in this version.

HP-UX in common in ./config). Note that for the moment of this writing
none of 64-bit platforms pass bntest. I'm committing this anyway as it's
too frustrating to patch snapshots over and over while 0.9.6 is known to
work.

circumstances.

More linker bloat reorganisation:

Split private key PEM and normal PEM handling. Private key
handling needs to link in stuff like PKCS#8.

Relocate the ASN1 *_dup() functions, to the relevant ASN1
modules using new macro IMPLEMENT_ASN1_DUP_FUNCTION. Previously
these were all in crypto/x509/x_all.c along with every ASN1
BIO/fp function which linked in *every* ASN1 function if
a single dup was used.

Move the authority key id ASN1 structure to a separate file.
This is used in the X509 routines and its previous location
linked in all the v3 extension code.

Also move ASN1_tag2bit to avoid linking in a_bytes.c which
is now largely obsolete.

So far under Linux stripped binary with single PEM_read_X509
is now 238K compared to 380K before these changes.

First of several reorganisations to
reduce linker bloat. For example the
single line:

PEM_read_X509()

results in a binary of around 400K in Linux!

This first step separates some of the PEM functions and
avoids linking in some PKCS#7 and PKCS#12 code.

or bogus DH parameters can be used for launching DOS attacks

Submitted by: Travis Vitek <vitek@roguewave.com>

OpenBSD /dev/crypto (this will be revamped later when the appropriate machinery
is available).

does not contain more bytes than the RSA modulus 'n' - it does not check
that the input is strictly *less* than 'n'. Whether this should be the
case or not is open to debate - however, due to security problems with
returning miscalculated CRT results, the 'rsa_mod_exp' implementation in
rsa_eay.c now performs a public-key exponentiation to verify the CRT result
and in the event of an error will instead recalculate and return a non-CRT
(more expensive) mod_exp calculation. As the mod_exp of 'I' is equivalent
to the mod_exp of 'I mod n', and the verify result is automatically between
0 and n-1 inclusive, the verify only matches the input if 'I' was less than
'n', otherwise even a correct CRT calculation is only congruent to 'I' (ie.
they differ by a multiple of 'n'). Rather than rejecting correct
calculations and doing redundant and slower ones instead, this changes the
equality check in the verification code to a congruence check.

certificate so need to match its subject with the certificate IDs in the
response.