Skip to content

T
Third Party Openssl

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

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 08 11月, 2019 1 次提交
  3. 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
  5. 18 4月, 2019 1 次提交
  7. 20 11月, 2018 1 次提交
  9. 16 11月, 2018 2 次提交
  11. 14 11月, 2018 1 次提交
  13. 12 11月, 2018 1 次提交
    • R
      Fix SipHash init order. · 61e78e7a
      由 Richard Levitte 提交于 
      Setting the SipHash hash size and setting its key is done with two
independent functions...  and yet, the internals depend on both.

Unfortunately, the function to change the size wasn't adapted for the
possibility that the key was set first, with a different hash size.

This changes the hash setting function to fix the internal values
(which is easy, fortunately) according to the hash size.

evpmac.txt value for digestsize:8 is also corrected.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7613)

(cherry picked from commit 425036130dfb3cfbef5937772f7526ce60133264)
      61e78e7a
  15. 10 11月, 2018 1 次提交
  17. 09 11月, 2018 1 次提交
  19. 08 11月, 2018 3 次提交
    • 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
    • D
      Test: link drbgtest statically against libcrypto · c39df745
      由 Dr. Matthias St. Pierre 提交于 
      and remove duplicate rand_drbg_seedlen() implementation again.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7462)

(cherry picked from commit 1c615e4ce97715ae3af9255bc57be32a49687966)
      c39df745
    • P
      Add missing RAND initialisation call. · f7258489
      由 Pauli 提交于 
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7587)

(cherry picked from commit ac765685d4b08a48cefffc71c434760045154dad)
      f7258489
  21. 07 11月, 2018 2 次提交
  23. 06 11月, 2018 4 次提交
  25. 03 11月, 2018 4 次提交
  27. 02 11月, 2018 1 次提交
  29. 31 10月, 2018 1 次提交
  31. 30 10月, 2018 1 次提交
  33. 29 10月, 2018 7 次提交
  35. 27 10月, 2018 3 次提交
    • B
      Fix data race in RAND_DRBG_generate · 1f985276
      由 Bernd Edlinger 提交于 
      Fixes #7394
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7399)

(cherry picked from commit a83dc59afa2e0207180d7218efed19b20d48de95)
      1f985276
    • D
      RAND_add()/RAND_seed(): fix failure on short input or low entropy · d597a9a8
      由 Dr. Matthias St. Pierre 提交于 
      Commit 5b4cb385c18a (#7382) introduced a bug which had the effect
that RAND_add()/RAND_seed() failed for buffer sizes less than
32 bytes. The reason was that now the added random data was used
exlusively as entropy source for reseeding. When the random input
was too short or contained not enough entropy, the DRBG failed
without querying the available entropy sources.

This commit makes drbg_add() act smarter: it checks the entropy
requirements explicitely. If the random input fails this check,
it won't be added as entropy input, but only as additional data.
More precisely, the behaviour depends on whether an os entropy
source was configured (which is the default on most os):

- If an os entropy source is avaible then we declare the buffer
  content as additional data by setting randomness to zero and
  trigger a regular   reseeding.

- If no os entropy source is available, a reseeding will fail
  inevitably. So drbg_add() uses a trick to mix the buffer contents
  into the DRBG state without forcing a reseeding: it generates a
  dummy random byte, using the buffer content as additional data.

Related-to: #7449
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)

(cherry picked from commit 8817215d5c52a76f2b184b624bde4df8556dee6d)
      d597a9a8
    • D
      Backport some DRBG renamings and typo fixes · 35a34508
      由 Dr. Matthias St. Pierre 提交于 
      In commit 8bf366519661 some renamings andd typo fixes were made
while adding back the DRBG-HMAC and DRBG-HASH implementation.
Since the commit could not be backported, a lot of unnecessary
differences between master and 1.1.1 were introduced.

These differences result in tiresome merge conflicts when
cherry-picking. To minimize these merge-conflicts, this patch
ports all 'non-feature' changes of commit 8bf366519661
(e.g., renamings of private variables, fixes of typographical
errors, comment changes) manually back to 1.1.1.

The commits a83dc59afa2e (#7399) and 8817215d5c52 (#7456)
failed to cherry-pick previously to 1.1.1, with this patch
they both cherry-pick without conflicts.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7505)
      35a34508
  37. 26 10月, 2018 3 次提交
  39. 23 10月, 2018 1 次提交