1. 23 3月, 2015 11 次提交
  2. 22 3月, 2015 1 次提交
  3. 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
  4. 20 3月, 2015 4 次提交
  5. 19 3月, 2015 11 次提交
  6. 18 3月, 2015 2 次提交
  7. 17 3月, 2015 7 次提交
    • 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
    • M
      Fix unintended sign extension · 3475c7a1
      Matt Caswell 提交于
      The function CRYPTO_128_unwrap_pad uses an 8 byte AIV (Alternative Initial
      Value). The least significant 4 bytes of this is placed into the local
      variable |ptext_len|. This is done as follows:
      
          ptext_len = (aiv[4] << 24) | (aiv[5] << 16) | (aiv[6] << 8) | aiv[7];
      
      aiv[4] is an unsigned char, but (aiv[4] << 24) is promoted to a *signed*
      int - therefore we could end up shifting into the sign bit and end up with
      a negative value. |ptext_len| is a size_t (typically 64-bits). If the
      result of the shifts is negative then the upper bits of |ptext_len| will
      all be 1.
      
      This commit fixes the issue by explicitly casting to an unsigned int.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      3475c7a1
    • M
      Fix seg fault in s_time · dfef52f6
      Matt Caswell 提交于
      Passing a negative value for the "-time" option to s_time results in a seg
      fault. This commit fixes it so that time has to be greater than 0.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      dfef52f6
    • M
      Add sanity check to PRF · 668f6f08
      Matt Caswell 提交于
      The function tls1_PRF counts the number of digests in use and partitions
      security evenly between them. There always needs to be at least one digest
      in use, otherwise this is an internal error. Add a sanity check for this.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      668f6f08
    • M
      Fix memset call in stack.c · 7132ac83
      Matt Caswell 提交于
      The function sk_zero is supposed to zero the elements held within a stack.
      It uses memset to do this. However it calculates the size of each element
      as being sizeof(char **) instead of sizeof(char *). This probably doesn't
      make much practical difference in most cases, but isn't a portable
      assumption.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      7132ac83