Skip to content

T
Third Party Openssl

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

通知 8
Star 18
Fork 1
T
Third Party Openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 11月, 2019 1 次提交
  3. 03 9月, 2019 1 次提交
  5. 14 6月, 2019 1 次提交
  7. 30 5月, 2019 1 次提交
  9. 28 5月, 2019 1 次提交
  11. 27 5月, 2019 1 次提交
  13. 20 4月, 2019 1 次提交
    • G
      TicketNo:AR000C11BK · 17ac3fa9
      由 g00368537 提交于 
      Description: Prevent over long nonces in ChaCha20-Poly1305

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

Team:PDU_DRV
Feature or Bugfix:Feature
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: I5085b1e79835cfae4d7122311d857c09a14e2420
Reviewed-on: http://mgit-tm.rnd.huawei.com/4573465Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nwangyanbo 00291255 <wangyanbo3@huawei.com>
Reviewed-by: Nxiaofuzhou 00203296 <xiaofuzhou@huawei.com>
      17ac3fa9
  15. 18 4月, 2019 1 次提交
  17. 20 11月, 2018 4 次提交
  19. 19 11月, 2018 1 次提交
  21. 16 11月, 2018 2 次提交
  23. 15 11月, 2018 1 次提交
  25. 14 11月, 2018 6 次提交
  27. 13 11月, 2018 1 次提交
    • V
      Added missing signature algorithm reflection functions · 45f24725
      由 Viktor Dukhovni 提交于 
          SSL_get_signature_nid()      -- local signature algorithm
    SSL_get_signature_type_nid() -- local signature algorithm key type
    SSL_get_peer_tmp_key()       -- Peer key-exchange public key
    SSL_get_tmp_key              -- local key exchange public key

Aliased pre-existing SSL_get_server_tmp_key(), which was formerly
just for clients, to SSL_get_peer_tmp_key().  Changed internal
calls to use the new name.
Reviewed-by: NMatt Caswell <matt@openssl.org>
      45f24725
  29. 12 11月, 2018 8 次提交
  31. 11 11月, 2018 1 次提交
  33. 10 11月, 2018 2 次提交
  35. 09 11月, 2018 5 次提交
  37. 08 11月, 2018 1 次提交
    • D
      rand_unix.c: open random devices on first use only · abf58ed3
      由 Dr. Matthias St. Pierre 提交于 
      Commit c7504aeb (pr #6432) fixed a regression for applications in
chroot environments, which compensated the fact that the new OpenSSL CSPRNG
(based on the NIST DRBG) now reseeds periodically, which the previous
one didn't. Now the reseeding could fail in the chroot environment if the
DEVRANDOM devices were not present anymore and no other entropy source
(e.g. getrandom()) was available.

The solution was to keep the file handles for the DEVRANDOM devices open
by default. In fact, the fix did more than this, it opened the DEVRANDOM
devices early and unconditionally in rand_pool_init(), which had the
unwanted side effect that the devices were opened (and kept open) even
in cases when they were not used at all, for example when the getrandom()
system call was available. Due  to a bug (issue #7419) this even happened
when the feature was disabled by the application.

This commit removes the unconditional opening of all DEVRANDOM devices.
They will now only be opened (and kept open) on first use. In particular,
if getrandom() is available, the handles will not be opened unnecessarily.

This change does not introduce a regression for applications compiled for
libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the
above constellation the CSPRNG will only be properly seeded if it is happens
before the forking and chrooting.

Fixes #7419
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7437)

(cherry picked from commit 8cfc19716c22dac737ec8cfc5f7d085e7c37f4d8)
      abf58ed3