Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
10 个月 前同步成功

通知 8
Star 18
Fork 1
T
Third Party Openssl

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 11 3月, 2019 2 次提交
  3. 08 3月, 2019 6 次提交
  5. 07 3月, 2019 2 次提交
    • M
      Add a test for underflow in ecp_nistp521.c · acd9b16b
      由 Matt Caswell 提交于 
      The previous commit fixed an underflow that may occur in ecp_nistp521.c.
This commit adds a test for that condition. It is heavily based on an
original test harness by Billy Brumley.
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8405)

(cherry picked from commit 6855b496b205c067ecb276221c31c6212f4fdbae)
      acd9b16b
    • M
      Avoid an underflow in ecp_nistp521.c · d49b8889
      由 Matt Caswell 提交于 
      The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in|
from |out| mod p. In order to avoid underflow it first adds 32p mod p
(which is equivalent to 0 mod p) to |out|. The comments and variable naming
suggest that the original author intended to add 64p mod p. In fact it
has been shown that with certain unusual co-ordinates it is possible to
cause an underflow in this function when only adding 32p mod p while
performing a point double operation. By changing this to 64p mod p the
underflow is avoided.

It turns out to be quite difficult to construct points that satisfy the
underflow criteria although this has been done and the underflow
demonstrated. However none of these points are actually on the curve.
Finding points that satisfy the underflow criteria and are also *on* the
curve is considered significantly more difficult. For this reason we do
not believe that this issue is currently practically exploitable and
therefore no CVE has been assigned.

This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure
option.

With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant
help in investigating this issue.
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8405)

(cherry picked from commit 13fbce17fc9f02e2401fc3868f3f8e02d6647e5f)
      d49b8889
  7. 06 3月, 2019 3 次提交
    • M
      Update ChaCha20-Poly1305 documentation · f7a6d112
      由 Matt Caswell 提交于 
      Correctly describe the maximum IV length.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8406)

(cherry picked from commit 27d5631236325c3fd8a3bd06af282ac496aac64b)
      f7a6d112
    • M
      Test an overlong ChaCha20-Poly1305 nonce · 9b10d1bf
      由 Matt Caswell 提交于 
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8406)

(cherry picked from commit a4f0b50eafb256bb802f2724fc7f7580fb0fbabc)
      9b10d1bf
    • M
      Prevent over long nonces in ChaCha20-Poly1305 · f426625b
      由 Matt Caswell 提交于 
      ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for
every encryption operation. RFC 7539 specifies that the nonce value (IV)
should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and
front pads the nonce with 0 bytes if it is less than 12 bytes. However it
also incorrectly allows a nonce to be set of up to 16 bytes. In this case
only the last 12 bytes are significant and any additional leading bytes are
ignored.

It is a requirement of using this cipher that nonce values are unique.
Messages encrypted using a reused nonce value are susceptible to serious
confidentiality and integrity attacks. If an application changes the
default nonce length to be longer than 12 bytes and then makes a change to
the leading bytes of the nonce expecting the new value to be a new unique
nonce then such an application could inadvertently encrypt messages with a
reused nonce.

Additionally the ignored bytes in a long nonce are not covered by the
integrity guarantee of this cipher. Any application that relies on the
integrity of these ignored leading bytes of a long nonce may be further
affected.

Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe
because no such use sets such a long nonce value. However user
applications that use this cipher directly and set a non-default nonce
length to be longer than 12 bytes may be vulnerable.

CVE-2019-1543

Fixes #8345
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8406)

(cherry picked from commit 2a3d0ee9d59156c48973592331404471aca886d6)
      f426625b
  9. 05 3月, 2019 1 次提交
  11. 04 3月, 2019 1 次提交
  13. 02 3月, 2019 1 次提交
  15. 01 3月, 2019 1 次提交
  17. 28 2月, 2019 6 次提交
  19. 27 2月, 2019 6 次提交
  21. 26 2月, 2019 11 次提交