- Jul 31, 2001
-
-
Richard Levitte authored
-
- Jul 30, 2001
-
-
Ben Laurie authored
-
Ben Laurie authored
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.
-
Ben Laurie authored
-
Andy Polyakov authored
-
Andy Polyakov authored
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.
-
Andy Polyakov authored
-
Ben Laurie authored
-
Andy Polyakov authored
-
Lutz Jänicke authored
-
Lutz Jänicke authored
-
Lutz Jänicke authored
-
- Jul 27, 2001
-
-
Bodo Möller authored
-
Bodo Möller authored
-
Lutz Jänicke authored
circumstances.
-
Richard Levitte authored
-
Dr. Stephen Henson authored
-
Dr. Stephen Henson authored
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.
-
- Jul 26, 2001
-
-
Dr. Stephen Henson authored
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.
-
Lutz Jänicke authored
-
- Jul 25, 2001
-
-
Bodo Möller authored
or bogus DH parameters can be used for launching DOS attacks
-
Bodo Möller authored
-
Bodo Möller authored
-
Bodo Möller authored
-
Andy Polyakov authored
explicitely noted that 64-bit SPARCv9 ABI is not officially supported by GCC 3.0 (support is scheduled for 3.1 release), but it appears to work, at the very least 'make test' passes...
-
Lutz Jänicke authored
-
Bodo Möller authored
-
- Jul 24, 2001
-
-
Bodo Möller authored
-
Bodo Möller authored
Submitted by: Travis Vitek <vitek@roguewave.com>
-
- Jul 23, 2001
-
-
Geoff Thorpe authored
possible problems. - New file breakage.c handles (so far) missing functions. - Get rid of some signed/unsigned/const warnings thanks to solaris-cc - Add autoconf/automake input files, and helper scripts to populate missing (but auto-generated) files. This change adds a configure.in and Makefile.am to build everything using autoconf, automake, and libtool - and adds "gunk" scripts to generate the various files those things need (and clean then up again after). This means that "autogunk.sh" needs to be run first on a system with the autotools, but the resulting directory should be "configure"able and compilable on systems without those tools.
-
Lutz Jänicke authored
-
Lutz Jänicke authored
-
- Jul 22, 2001
-
-
Geoff Thorpe authored
-
- Jul 21, 2001
-
-
Richard Levitte authored
-
Lutz Jänicke authored
-
Ben Laurie authored
OpenBSD /dev/crypto (this will be revamped later when the appropriate machinery is available).
-
Richard Levitte authored
His comments are: This patch fixes the problem of modern Kerberos using "derived keys" to encrypt the authenticator by disabling the authenticator check for all derived keys enctypes. I think I've got all the bugfixes that Jeffrey and I discussed rolled into this. There were some problems with Jeffrey's code to convert the authenticator's Kerberos timestring into struct tm (e.g. Z, -1900; it helps to have an actual decryptable authenticator to play with). So I've shamelessly pushed in my code, while stealing some bits from Jeffrey.
-
- Jul 20, 2001
-
-
Lutz Jänicke authored
-
Lutz Jänicke authored
-
Geoff Thorpe authored
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.
-