1. 24 3月, 2015 3 次提交
  2. 23 3月, 2015 12 次提交
  3. 22 3月, 2015 1 次提交
  4. 21 3月, 2015 4 次提交
    • D
      Add AES unwrap test with invalid key. · 77e127ea
      Dr. Stephen Henson 提交于
      This tests the unwrap algorithm with an invalid key. The result should
      be rejected without returning any plaintext.
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      77e127ea
    • D
      Fix memory leak. · 5724bd49
      Dr. Stephen Henson 提交于
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      5724bd49
    • R
      CRYPTO_128_unwrap(): Fix refactoring damage · e6abba3a
      Richard Godbee 提交于
      crypto/modes/wrap128.c was heavily refactored to support AES Key Wrap
      with Padding, and four bugs were introduced into CRYPTO_128_unwrap() at
      that time:
      
      - crypto_128_unwrap_raw()'s return value ('ret') is checked incorrectly,
        and the function immediately returns 'ret' in (almost) all cases.
        This makes the IV checking code later in the function unreachable, but
        callers think the IV check succeeded since CRYPTO_128_unwrap()'s
        return value is non-zero.
      
        FIX: Return 0 (error) if crypto_128_unwrap_raw() returned 0 (error).
      
      - crypto_128_unwrap_raw() writes the IV to the 'got_iv' buffer, not to
        the first 8 bytes of the output buffer ('out') as the IV checking code
        expects.  This makes the IV check fail.
      
        FIX: Compare 'iv' to 'got_iv', not 'out'.
      
      - The data written to the output buffer ('out') is "cleansed" if the IV
        check fails, but the code passes OPENSSL_cleanse() the input buffer
        length ('inlen') instead of the number of bytes that
        crypto_128_unwrap_raw() wrote to the output buffer ('ret').  This
        means that OPENSSL_cleanse() could potentially write past the end of
        'out'.
      
        FIX: Change 'inlen' to 'ret' in the OPENSSL_cleanse() call.
      
      - CRYPTO_128_unwrap() is returning the length of the input buffer
        ('inlen') instead of the number of bytes written to the output buffer
        ('ret').  This could cause the caller to read past the end of 'out'.
      
        FIX: Return 'ret' instead of 'inlen' at the end of the function.
      
      PR#3749
      Reviewed-by: NStephen Henson <steve@openssl.org>
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      e6abba3a
    • R
      wrap128.c: Fix Doxygen comments · 1062ecfc
      Richard Godbee 提交于
      Reviewed-by: NStephen Henson <steve@openssl.org>
      Reviewed-by: NEmilia Käsper <emilia@openssl.org>
      1062ecfc
  5. 20 3月, 2015 4 次提交
  6. 19 3月, 2015 11 次提交
  7. 18 3月, 2015 2 次提交
  8. 17 3月, 2015 3 次提交
    • M
      Dead code removal from apps · 11abf922
      Matt Caswell 提交于
      Some miscellaneous removal of dead code from apps. Also fix an issue with
      error handling with pkcs7.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      11abf922
    • M
      Remove dead code from crypto · b7573c59
      Matt Caswell 提交于
      Some miscellaneous removal of dead code from lib crypto.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      b7573c59
    • M
      Fix probable_prime over large shift · e4676e90
      Matt Caswell 提交于
      In the probable_prime() function we behave slightly different if the number
      of bits we are interested in is <= BN_BITS2 (the num of bits in a BN_ULONG).
      As part of the calculation we work out a size_limit as follows:
      
          size_limit = (((BN_ULONG)1) << bits) - BN_get_word(rnd) - 1;
      
      There is a problem though if bits == BN_BITS2. Shifting by that much causes
      undefined behaviour. I did some tests. On my system BN_BITS2 == 64. So I
      set bits to 64 and calculated the result of:
      
          (((BN_ULONG)1) << bits)
      
      I was expecting to get the result 0. I actually got 1! Strangely this...
      
          (((BN_ULONG)0) << BN_BITS2)
      
      ...does equal 0! This means that, on my system at least, size_limit will be
      off by 1 when bits == BN_BITS2.
      
      This commit fixes the behaviour so that we always get consistent results.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      e4676e90