1. 31 10月, 2017 3 次提交
  2. 18 10月, 2017 1 次提交
  3. 13 10月, 2017 1 次提交
  4. 12 10月, 2017 4 次提交
  5. 09 10月, 2017 1 次提交
  6. 15 9月, 2017 1 次提交
  7. 14 9月, 2017 4 次提交
  8. 12 9月, 2017 1 次提交
  9. 30 8月, 2017 3 次提交
  10. 22 8月, 2017 2 次提交
  11. 16 8月, 2017 1 次提交
  12. 15 8月, 2017 1 次提交
  13. 12 8月, 2017 2 次提交
  14. 08 8月, 2017 1 次提交
  15. 03 8月, 2017 1 次提交
    • R
      Switch from ossl_rand to DRBG rand · 75e2c877
      Rich Salz 提交于
      If RAND_add wraps around, XOR with existing. Add test to drbgtest that
      does the wrap-around.
      
      Re-order seeding and stop after first success.
      
      Add RAND_poll_ex()
      
      Use the DF and therefore lower RANDOMNESS_NEEDED.  Also, for child DRBG's,
      mix in the address as the personalization bits.
      
      Centralize the entropy callbacks, from drbg_lib to rand_lib.
      (Conceptually, entropy is part of the enclosing application.)
      Thanks to Dr. Matthias St Pierre for the suggestion.
      
      Various code cleanups:
          -Make state an enum; inline RANDerr calls.
          -Add RAND_POLL_RETRIES (thanks Pauli for the idea)
          -Remove most RAND_seed calls from rest of library
          -Rename DRBG_CTX to RAND_DRBG, etc.
          -Move some code from drbg_lib to drbg_rand; drbg_lib is now only the
           implementation of NIST DRBG.
          -Remove blocklength
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/4019)
      75e2c877
  16. 02 8月, 2017 1 次提交
    • M
      Adding NID_hmac_sha1 and _md5 to builtin_pbe[] · 418d49c2
      Martin Peylo 提交于
      The OID for {1 3 6 1 5 5 8 1 2} HMAC-SHA1 (NID_hmac_sha1) is explicitly
      referenced by RFC 2510, RFC 3370, and RFC 4210. This is essential for the
      common implementations of CMP (Certificate Managing Protocol, RFC4210).
      
      HMAC-MD5's OID {1 3 6 1 5 5 8 1 1} (NID_hmac_md5) is in the same branch and
      it seems to generally exist (-> Internet search), but it is unclear where it is
      actually defined as it appears not to be referenced by RFCs and practically
      rather unused.
      
      Those OIDs are both duplicates to OIDs from an RSA OID branch, which are already
      included in builtin_pbe[]:
      
      HMAC-SHA1 also has another OID defined in PKCS#5/RFC2898 (NID_hmacWithSHA1).
      
      It is also unclear where the other OID for HMAC-MD5 (NID_hmacWithMD5) from the
      RSA branch is officially specified, as only HMAC-SHA1 from PKCS#5 was found to be
      defined. Anyway, HMAC-MD5 likely only plays a neglectable role in the future.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/3811)
      418d49c2
  17. 30 7月, 2017 1 次提交
  18. 26 7月, 2017 2 次提交
  19. 25 7月, 2017 1 次提交
  20. 19 7月, 2017 2 次提交
    • M
      Remove some dead code · d5475e31
      Matt Caswell 提交于
      The intention of the removed code was to check if the previous operation
      carried. However this does not work. The "mask" value always ends up being
      a constant and is all ones - thus it has no effect. This check is no longer
      required because of the previous commit.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3832)
      d5475e31
    • M
      Fix undefined behaviour in e_aes_cbc_hmac_sha256.c and e_aes_cbc_hmac_sha1.c · 335d0a46
      Matt Caswell 提交于
      In TLS mode of operation the padding value "pad" is obtained along with the
      maximum possible padding value "maxpad". If pad > maxpad then the data is
      invalid. However we must continue anyway because this is constant time code.
      
      We calculate the payload length like this:
      
          inp_len = len - (SHA_DIGEST_LENGTH + pad + 1);
      
      However if pad is invalid then inp_len ends up -ve (actually large +ve
      because it is a size_t).
      
      Later we do this:
      
          /* verify HMAC */
          out += inp_len;
          len -= inp_len;
      
      This ends up with "out" pointing before the buffer which is undefined
      behaviour. Next we calculate "p" like this:
      
          unsigned char *p =
              out + len - 1 - maxpad - SHA256_DIGEST_LENGTH;
      
      Because of the "out + len" term the -ve inp_len value is cancelled out
      so "p" points to valid memory (although technically the pointer arithmetic
      is undefined behaviour again).
      
      We only ever then dereference "p" and never "out" directly so there is
      never an invalid read based on the bad pointer - so there is no security
      issue.
      
      This commit fixes the undefined behaviour by ensuring we use maxpad in
      place of pad, if the supplied pad is invalid.
      
      With thanks to Brian Carpenter for reporting this issue.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3832)
      335d0a46
  21. 07 7月, 2017 1 次提交
  22. 05 7月, 2017 2 次提交
  23. 03 7月, 2017 2 次提交
  24. 15 6月, 2017 1 次提交