Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
1 年多 前同步成功

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 24 4月, 2018 10 次提交
  3. 23 4月, 2018 11 次提交
  5. 20 4月, 2018 2 次提交
  7. 19 4月, 2018 3 次提交
  9. 18 4月, 2018 2 次提交
  11. 17 4月, 2018 3 次提交
  13. 16 4月, 2018 1 次提交
  15. 14 4月, 2018 3 次提交
    • M
      openssl#5668: corrections after compiling with -qinfo=all:als. · d47eb76c
      由 Matthias Kraft 提交于 
      The ongoing discussion about casting or not in PR #5626 had me compiling
again with above mentioned flags. Indeed the compiler had to say something
about it and I did these changes to silence it again.
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5943)
      d47eb76c
    • R
      make update · 560096f8
      由 Richard Levitte 提交于 
      Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5948)
      560096f8
    • D
      DRBG: implement a get_nonce() callback · 5bc6bcf8
      由 Dr. Matthias St. Pierre 提交于 
      Fixes #5849

In pull request #5503 a fallback was added which adds a random nonce of
security_strength/2 bits if no nonce callback is provided. This change raised
the entropy requirements form 256 to 384 bit, which can cause problems on some
platforms (e.g. VMS, see issue #5849).

The requirements for the nonce are given in section 8.6.7 of NIST SP 800-90Ar1:

  A nonce may be required in the construction of a seed during instantiation
  in order to provide a security cushion to block certain attacks.
  The nonce shall be either:

  a) A value with at least (security_strength/2) bits of entropy, or

  b) A value that is expected to repeat no more often than a
     (security_strength/2)-bit random string would be expected to repeat.

  Each nonce shall be unique to the cryptographic module in which instantiation
  is performed, but need not be secret. When used, the nonce shall be considered
  to be a critical security parameter.

This commit implements a nonce of type b) in order to lower the entropy
requirements during instantiation back to 256 bits.

The formulation "shall be unique to the cryptographic module" above implies
that the nonce needs to be unique among (with high probability) among all
DRBG instances in "space" and "time". We try to achieve this goal by creating a
nonce of the following form

    nonce = app-specific-data || high-resolution-utc-timestamp || counter

Where || denotes concatenation. The application specific data can be something
like the process or group id of the application. A utc timestamp is used because
it increases monotonically, provided the system time is synchronized. This approach
may not be perfect yet for a FIPS evaluation, but it should be good enough for the
moment.

This commit also harmonizes the implementation of the get_nonce() and the
get_additional_data() callbacks and moves the platform specific parts from
rand_lib.c into rand_unix.c, rand_win.c, and rand_vms.c.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5920)
      5bc6bcf8
  17. 13 4月, 2018 2 次提交
    • M
      Add support for the SRP base64 alphabet · 3fd59700
      由 Matt Caswell 提交于 
      Historically we used to implement standalone base64 code for SRP. This
was replaced by commit 3d3f21aa with the standard base64 processing code.

However, the SRP base64 code was designed to be compatible with other SRP
libraries (notably libsrp, but also others) that use a variant of standard
base64. Specifically a different alphabet is used and no padding '='
characters are used. Instead 0 padding is added to the front of the string.
By changing to standard base64 we change the behaviour of the API which may
impact interoperability. It also means that SRP verifier files created prior
to 1.1.1 would not be readable in 1.1.1 and vice versa.

Instead we expand our standard base64 processing with the capability to be
able to read and generate the SRP base64 variant.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
      3fd59700
    • M
      Change SRP functions to use EVP_EncodeUpdate/EVP_DecodeUpdate functions · c0804614
      由 Matt Caswell 提交于 
      Previously they were using EVP_EncodeBlock/EVP_DecodeBlock. These are low
level functions that do not handle padding characters. This was causing
the SRP code to fail. One side effect of using EVP_EncodeUpdate is that
it inserts newlines which is not what we need in SRP so we add a flag to
avoid that.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
      c0804614
  19. 10 4月, 2018 2 次提交
  21. 09 4月, 2018 1 次提交