1. 16 7月, 2018 1 次提交
    • 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
  2. 11 7月, 2018 1 次提交
  3. 27 6月, 2018 2 次提交
  4. 19 6月, 2018 3 次提交
  5. 18 6月, 2018 2 次提交
  6. 08 6月, 2018 1 次提交
  7. 04 6月, 2018 4 次提交
  8. 30 5月, 2018 1 次提交
  9. 25 5月, 2018 1 次提交
  10. 03 5月, 2018 1 次提交
  11. 27 4月, 2018 2 次提交
  12. 25 4月, 2018 1 次提交
  13. 24 4月, 2018 1 次提交
  14. 14 4月, 2018 1 次提交
  15. 06 4月, 2018 2 次提交
  16. 05 4月, 2018 2 次提交
    • M
      Pick a q size consistent with the digest for DSA param generation · d54897cf
      Matt Caswell 提交于
      There are two undocumented DSA parameter generation options available in
      the genpkey command line app:
      dsa_paramgen_md and dsa_paramgen_q_bits.
      
      These can also be accessed via the EVP API but only by using
      EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() directly. There are no
      helper macros for these options.
      
      dsa_paramgen_q_bits sets the length of q in bits (default 160 bits).
      dsa_paramgen_md sets the digest that is used during the parameter
      generation (default SHA1). In particular the output length of the digest
      used must be equal to or greater than the number of bits in q because of
      this code:
      
                  if (!EVP_Digest(seed, qsize, md, NULL, evpmd, NULL))
                      goto err;
                  if (!EVP_Digest(buf, qsize, buf2, NULL, evpmd, NULL))
                      goto err;
                  for (i = 0; i < qsize; i++)
                      md[i] ^= buf2[i];
      
                  /* step 3 */
                  md[0] |= 0x80;
                  md[qsize - 1] |= 0x01;
                  if (!BN_bin2bn(md, qsize, q))
                      goto err;
      
      qsize here is the number of bits in q and evpmd is the digest set via
      dsa_paramgen_md. md and buf2 are buffers of length SHA256_DIGEST_LENGTH.
      buf2 has been filled with qsize bits of random seed data, and md is
      uninitialised.
      
      If the output size of evpmd is less than qsize then the line "md[i] ^=
      buf2[i]" will be xoring an uninitialised value and the random seed data
      together to form the least significant bits of q (and not using the
      output of the digest at all for those bits) - which is probably not what
      was intended. The same seed is then used as an input to generating p. If
      the uninitialised data is actually all zeros (as seems quite likely)
      then the least significant bits of q will exactly match the least
      significant bits of the seed.
      
      This problem only occurs if you use these undocumented and difficult to
      find options and you set the size of q to be greater than the message
      digest output size. This is for parameter generation only not key
      generation. This scenario is considered highly unlikely and
      therefore the security risk of this is considered negligible.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5800)
      d54897cf
    • M
      Move the loading of the ssl_conf module to libcrypto · d8f031e8
      Matt Caswell 提交于
      The GOST engine needs to be loaded before we initialise libssl. Otherwise
      the GOST ciphersuites are not enabled. However the SSL conf module must
      be loaded before we initialise libcrypto. Otherwise we will fail to read
      the SSL config from a config file properly.
      
      Another problem is that an application may make use of both libcrypto and
      libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto()
      is called and loads a config file it will fail if that config file has
      any libssl stuff in it.
      
      This commit separates out the loading of the SSL conf module from the
      interpretation of its contents. The loading piece doesn't know anything
      about SSL so this can be moved to libcrypto. The interpretation of what it
      means remains in libssl. This means we can load the SSL conf data before
      libssl is there and interpret it when it later becomes available.
      
      Fixes #5809
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5818)
      d8f031e8
  17. 04 4月, 2018 1 次提交
  18. 03 4月, 2018 1 次提交
  19. 30 3月, 2018 1 次提交
  20. 27 3月, 2018 1 次提交
  21. 19 3月, 2018 1 次提交
  22. 17 3月, 2018 2 次提交
  23. 16 3月, 2018 1 次提交
  24. 15 3月, 2018 3 次提交
  25. 14 3月, 2018 2 次提交
  26. 10 3月, 2018 1 次提交
    • T
      Add SSL/SSL_CTX_use_cert_and_key() · 37933acb
      Todd Short 提交于
      Add functions that will do the work of assigning certificate, privatekey
      and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the
      publickey. This will permit the keys to pass validation for both ECDSA
      and RSA. If a private key has already been set for the certificate, it
      is discarded. A real private key can be set later.
      
      This is an all-or-nothing setting of these parameters. Unlike the
      SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions,
      the existing cert or privatekey is not modified (i.e. parameters copied).
      This permits the existing cert/privatekey to be replaced.
      
      It replaces the sequence of:
      * SSL_use_certificate()
      * SSL_use_privatekey()
      * SSL_set1_chain()
      And may actually be faster, as multiple checks are consolidated.
      
      The private key can be NULL, if so an ENGINE module needs to contain the
      actual private key that is to be used.
      
      Note that ECDH (using the certificate's ECDSA key) ciphers do not work
      without the private key being present, based on how the private key is
      used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/1130)
      37933acb