1. 26 5月, 2023 1 次提交
  2. 12 4月, 2023 2 次提交
  3. 10 8月, 2021 1 次提交
  4. 17 3月, 2020 1 次提交
  5. 27 2月, 2020 1 次提交
  6. 05 1月, 2020 1 次提交
  7. 28 9月, 2019 2 次提交
    • 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
  8. 19 3月, 2019 1 次提交
  9. 21 2月, 2019 1 次提交
    • B
      SCA hardening for mod. field inversion in EC_GROUP · 48e82c8e
      Billy Brumley 提交于
      This commit adds a dedicated function in `EC_METHOD` to access a modular
      field inversion implementation suitable for the specifics of the
      implemented curve, featuring SCA countermeasures.
      
      The new pointer is defined as:
      `int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)`
      and computes the multiplicative inverse of `a` in the underlying field,
      storing the result in `r`.
      
      Three implementations are included, each including specific SCA
      countermeasures:
        - `ec_GFp_simple_field_inv()`, featuring SCA hardening through
          blinding.
        - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's
          Little Theorem (FLT) inversion.
        - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which
          already features SCA hardening through blinding.
      
      From a security point of view, this also helps addressing a leakage
      previously affecting conversions from projective to affine coordinates.
      
      This commit also adds a new error reason code (i.e.,
      `EC_R_CANNOT_INVERT`) to improve consistency between the three
      implementations as all of them could fail for the same reason but
      through different code paths resulting in inconsistent error stack
      states.
      Co-authored-by: NNicola Tuveri <nic.tuv@gmail.com>
      
      (cherry picked from commit e0033efc30b0f00476bba8f0fa5512be5dc8a3f1)
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8262)
      48e82c8e
  10. 25 7月, 2018 1 次提交
  11. 22 7月, 2018 1 次提交
  12. 16 7月, 2018 2 次提交
    • N
      EC2M Lopez-Dahab ladder: use it also for ECDSA verify · 01ad66f8
      Nicola Tuveri 提交于
      By default `ec_scalar_mul_ladder` (which uses the Lopez-Dahab ladder
      implementation) is used only for (k * Generator) or (k * VariablePoint).
      ECDSA verification uses (a * Generator + b * VariablePoint): this commit
      forces the use of `ec_scalar_mul_ladder` also for the ECDSA verification
      path, while using the default wNAF implementation for any other case.
      
      With this commit `ec_scalar_mul_ladder` loses the static attribute, and
      is added to ec_lcl.h so EC_METHODs can directly use it.
      
      While working on a new custom EC_POINTs_mul implementation, I realized
      that many checks (e.g. all the points being compatible with the given
      EC_GROUP, creating a temporary BN_CTX if `ctx == NULL`, check for the
      corner case `scalar == NULL && num == 0`) were duplicated again and
      again in every single implementation (and actually some
      implementations lacked some of the tests).
      I thought that it makes way more sense for those checks that are
      independent from the actual implementation and should always be done, to
      be moved in the EC_POINTs_mul wrapper: so this commit also includes
      these changes.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6690)
      01ad66f8
    • N
      EC point multiplication: add `ladder` scaffold · 37124360
      Nicola Tuveri 提交于
      for specialized Montgomery ladder implementations
      
      PR #6009 and #6070 replaced the default EC point multiplication path for
      prime and binary curves with a unified Montgomery ladder implementation
      with various timing attack defenses (for the common paths when a secret
      scalar is feed to the point multiplication).
      The newly introduced default implementation directly used
      EC_POINT_add/dbl in the main loop.
      
      The scaffolding introduced by this commit allows EC_METHODs to define a
      specialized `ladder_step` function to improve performances by taking
      advantage of efficient formulas for differential addition-and-doubling
      and different coordinate systems.
      
      - `ladder_pre` is executed before the main loop of the ladder: by
        default it copies the input point P into S, and doubles it into R.
        Specialized implementations could, e.g., use this hook to transition
        to different coordinate systems before copying and doubling;
      - `ladder_step` is the core of the Montgomery ladder loop: by default it
        computes `S := R+S; R := 2R;`, but specific implementations could,
        e.g., implement a more efficient formula for differential
        addition-and-doubling;
      - `ladder_post` is executed after the Montgomery ladder loop: by default
        it's a noop, but specialized implementations could, e.g., use this
        hook to transition back from the coordinate system used for optimizing
        the differential addition-and-doubling or recover the y coordinate of
        the result point.
      
      This commit also renames `ec_mul_consttime` to `ec_scalar_mul_ladder`,
      as it better corresponds to what this function does: nothing can be
      truly said about the constant-timeness of the overall execution of this
      function, given that the underlying operations are not necessarily
      constant-time themselves.
      What this implementation ensures is that the same fixed sequence of
      operations is executed for each scalar multiplication (for a given
      EC_GROUP), with no dependency on the value of the input scalar.
      Co-authored-by: NSohaib ul Hassan <soh.19.hassan@gmail.com>
      Co-authored-by: NBilly Brumley <bbrumley@gmail.com>
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6690)
      37124360
  13. 22 6月, 2018 1 次提交
  14. 19 6月, 2018 1 次提交
    • S
      Implement coordinate blinding for EC_POINT · f667820c
      Sohaib ul Hassan 提交于
      This commit implements coordinate blinding, i.e., it randomizes the
      representative of an elliptic curve point in its equivalence class, for
      prime curves implemented through EC_GFp_simple_method,
      EC_GFp_mont_method, and EC_GFp_nist_method.
      
      This commit is derived from the patch
      https://marc.info/?l=openssl-dev&m=131194808413635 by Billy Brumley.
      
      Coordinate blinding is a generally useful side-channel countermeasure
      and is (mostly) free. The function itself takes a few field
      multiplicationss, but is usually only necessary at the beginning of a
      scalar multiplication (as implemented in the patch). When used this way,
      it makes the values that variables take (i.e., field elements in an
      algorithm state) unpredictable.
      
      For instance, this mitigates chosen EC point side-channel attacks for
      settings such as ECDH and EC private key decryption, for the
      aforementioned curves.
      
      For EC_METHODs using different coordinate representations this commit
      does nothing, but the corresponding coordinate blinding function can be
      easily added in the future to extend these changes to such curves.
      Co-authored-by: NNicola Tuveri <nic.tuv@gmail.com>
      Co-authored-by: NBilly Brumley <bbrumley@gmail.com>
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6501)
      f667820c
  15. 25 5月, 2018 1 次提交
  16. 09 1月, 2018 2 次提交
  17. 08 1月, 2018 3 次提交
  18. 30 8月, 2017 2 次提交
  19. 01 7月, 2017 1 次提交
  20. 02 5月, 2017 1 次提交
  21. 18 11月, 2016 1 次提交
  22. 22 9月, 2016 1 次提交
  23. 24 8月, 2016 2 次提交
  24. 22 8月, 2016 1 次提交
  25. 18 5月, 2016 1 次提交
  26. 09 5月, 2016 1 次提交
  27. 09 3月, 2016 1 次提交
  28. 02 3月, 2016 1 次提交
  29. 29 2月, 2016 1 次提交
  30. 23 2月, 2016 1 次提交
  31. 01 2月, 2016 1 次提交
  32. 31 1月, 2016 1 次提交