1. 27 2月, 2023 1 次提交
  2. 17 3月, 2022 1 次提交
  3. 30 1月, 2022 1 次提交
  4. 10 8月, 2021 1 次提交
  5. 01 6月, 2020 1 次提交
  6. 31 5月, 2020 1 次提交
  7. 31 3月, 2020 1 次提交
  8. 19 3月, 2020 2 次提交
  9. 17 3月, 2020 1 次提交
  10. 27 2月, 2020 1 次提交
  11. 17 2月, 2020 1 次提交
  12. 06 2月, 2020 1 次提交
  13. 21 1月, 2020 1 次提交
  14. 17 1月, 2020 1 次提交
  15. 02 1月, 2020 1 次提交
  16. 21 12月, 2019 2 次提交
  17. 06 12月, 2019 2 次提交
  18. 17 11月, 2019 1 次提交
  19. 03 11月, 2019 1 次提交
  20. 31 10月, 2019 1 次提交
  21. 23 10月, 2019 1 次提交
  22. 17 10月, 2019 2 次提交
  23. 28 9月, 2019 3 次提交
    • D
      Fix header file include guard names · fbbfd128
      Dr. Matthias St. Pierre 提交于
      Make the include guards consistent by renaming them systematically according
      to the naming conventions below
      
      The public header files (in the 'include/openssl' directory) are not changed
      in 1.1.1, because it is a stable release.
      
      For the private header files files, the guard names try to match the path
      specified in the include directives, with all letters converted to upper case
      and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      fbbfd128
    • D
      Reorganize local header files · b5acbf91
      Dr. Matthias St. Pierre 提交于
      Apart from public and internal header files, there is a third type called
      local header files, which are located next to source files in the source
      directory. Currently, they have different suffixes like
      
        '*_lcl.h', '*_local.h', or '*_int.h'
      
      This commit changes the different suffixes to '*_local.h' uniformly.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      b5acbf91
    • D
      Reorganize private crypto header files · 0c994d54
      Dr. Matthias St. Pierre 提交于
      Currently, there are two different directories which contain internal
      header files of libcrypto which are meant to be shared internally:
      
      While header files in 'include/internal' are intended to be shared
      between libcrypto and libssl, the files in 'crypto/include/internal'
      are intended to be shared inside libcrypto only.
      
      To make things complicated, the include search path is set up in such
      a way that the directive #include "internal/file.h" could refer to
      a file in either of these two directoroes. This makes it necessary
      in some cases to add a '_int.h' suffix to some files to resolve this
      ambiguity:
      
        #include "internal/file.h"      # located in 'include/internal'
        #include "internal/file_int.h"  # located in 'crypto/include/internal'
      
      This commit moves the private crypto headers from
      
        'crypto/include/internal'  to  'include/crypto'
      
      As a result, the include directives become unambiguous
      
        #include "internal/file.h"       # located in 'include/internal'
        #include "crypto/file.h"         # located in 'include/crypto'
      
      hence the superfluous '_int.h' suffixes can be stripped.
      
      The files 'store_int.h' and 'store.h' need to be treated specially;
      they are joined into a single file.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      0c994d54
  24. 10 9月, 2019 1 次提交
  25. 07 9月, 2019 3 次提交
    • N
      Uniform BN_bn2binpad() and BN_bn2lebinpad() implementations · 2432e129
      Nicola Tuveri 提交于
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/9511)
      
      (cherry picked from commit 1b338abe3abb8c73f004c34d4b8a9272b89dfd5d)
      2432e129
    • N
      Make BN_num_bits() consttime upon BN_FLG_CONSTTIME · b9a380f7
      Nicola Tuveri 提交于
      This issue was partially addressed by commit
      972c87df, which hardened its callee
      BN_num_bits_word() to avoid leaking the most-significant word of its
      argument via branching and memory access pattern.
      The commit message also reported:
      > There are a few places where BN_num_bits is called on an input where
      > the bit length is also secret. This does *not* fully resolve those
      > cases as we still only look at the top word.
      
      BN_num_bits() is called directly or indirectly (e.g., through
      BN_num_bytes() or BN_bn2binpad() ) in various parts of the `crypto/ec`
      code, notably in all the currently supported implementations of scalar
      multiplication (in the generic path through ec_scalar_mul_ladder() as
      well as in dedicated methods like ecp_nistp{224,256,521}.c and
      ecp_nistz256.c).
      
      Under the right conditions, a motivated SCA attacker could retrieve the
      secret bitlength of a secret nonce through this vulnerability,
      potentially leading, ultimately, to recover a long-term secret key.
      
      With this commit, exclusively for BIGNUMs that are flagged with
      BN_FLG_CONSTTIME, instead of accessing only bn->top, all the limbs of
      the BIGNUM are accessed up to bn->dmax and bitwise masking is used to
      avoid branching.
      
      Memory access pattern still leaks bn->dmax, the size of the lazily
      allocated buffer for representing the BIGNUM, which is inevitable with
      the current BIGNUM architecture: reading past bn->dmax would be an
      out-of-bound read.
      As such, it's the caller responsibility to ensure that bn->dmax does not
      leak secret information, by explicitly expanding the internal BIGNUM
      buffer to a public value sufficient to avoid any lazy reallocation
      while manipulating it: this should be already done at the top level
      alongside setting the BN_FLG_CONSTTIME.
      
      Thanks to David Schrammel and Samuel Weiser for reporting this issue
      through responsible disclosure.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/9511)
      
      (cherry picked from commit 8b44198b916015f77bef1befa26edb48ad8a0238)
      b9a380f7
    • B
      Fix a SCA leak in BN_generate_dsa_nonce · 9e1403d9
      Bernd Edlinger 提交于
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/9782)
      
      (cherry picked from commit 31ca19403d56ad71d823cf62990518dfc6905bb4)
      9e1403d9
  26. 01 8月, 2019 1 次提交
  27. 23 7月, 2019 1 次提交
  28. 07 7月, 2019 1 次提交
  29. 11 6月, 2019 1 次提交
  30. 28 5月, 2019 1 次提交
  31. 19 3月, 2019 2 次提交