1. 04 11月, 2002 1 次提交
  2. 31 5月, 2002 1 次提交
  3. 26 9月, 2001 1 次提交
    • G
      This commits changes to various parts of libcrypto required by the recent · cb78486d
      Geoff Thorpe 提交于
      ENGINE surgery. DH, DSA, RAND, and RSA now use *both* "method" and ENGINE
      pointers to manage their hooking with ENGINE. Previously their use of
      "method" pointers was replaced by use of ENGINE references. See
      crypto/engine/README for details.
      
      Also, remove the ENGINE iterations from evp_test - even when the
      cipher/digest code is committed in, this functionality would require a
      different set of API calls.
      cb78486d
  4. 20 9月, 2001 1 次提交
  5. 26 7月, 2001 1 次提交
  6. 20 7月, 2001 1 次提交
    • G
      Currently, RSA code, when using no padding scheme, simply checks that input · 81d1998e
      Geoff Thorpe 提交于
      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.
      81d1998e
  7. 28 3月, 2001 2 次提交
  8. 20 2月, 2001 1 次提交
    • R
      Make all configuration macros available for application by making · cf1b7d96
      Richard Levitte 提交于
      sure they are available in opensslconf.h, by giving them names starting
      with "OPENSSL_" to avoid conflicts with other packages and by making
      sure e_os2.h will cover all platform-specific cases together with
      opensslconf.h.
      
      I've checked fairly well that nothing breaks with this (apart from
      external software that will adapt if they have used something like
      NO_KRB5), but I can't guarantee it completely, so a review of this
      change would be a good thing.
      cf1b7d96
  9. 19 12月, 2000 3 次提交
  10. 18 12月, 2000 1 次提交
  11. 07 11月, 2000 2 次提交
  12. 27 10月, 2000 1 次提交
  13. 02 6月, 2000 1 次提交
    • R
      There have been a number of complaints from a number of sources that names · 26a3a48d
      Richard Levitte 提交于
      like Malloc, Realloc and especially Free conflict with already existing names
      on some operating systems or other packages.  That is reason enough to change
      the names of the OpenSSL memory allocation macros to something that has a
      better chance of being unique, like prepending them with OPENSSL_.
      
      This change includes all the name changes needed throughout all C files.
      26a3a48d
  14. 04 2月, 2000 1 次提交
  15. 09 9月, 1999 1 次提交
  16. 28 7月, 1999 1 次提交
  17. 27 4月, 1999 2 次提交
  18. 24 4月, 1999 1 次提交
  19. 20 4月, 1999 1 次提交
  20. 11 3月, 1999 1 次提交
  21. 18 2月, 1999 1 次提交
  22. 08 1月, 1999 1 次提交
  23. 05 1月, 1999 1 次提交
  24. 30 12月, 1998 1 次提交
  25. 21 12月, 1998 3 次提交