- 27 2月, 2023 1 次提交
-
-
由 Matt Caswell 提交于
A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. Patch written by Dmitry Belyavsky and Hubert Kario CVE-2022-4304 Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: NTomas Mraz <tomas@openssl.org> Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 17 3月, 2022 1 次提交
-
-
https://gitee.com/haixiangw/third_party_openssl/pulls/32由 haixiangw 提交于
fix CVE-2022-0778 Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>
-
- 30 1月, 2022 1 次提交
-
-
由 haixiangw 提交于
Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>
-
- 10 8月, 2021 1 次提交
-
-
由 HJ 提交于
Signed-off-by: NHJ <huangjun42@huawei.com>
-
- 01 6月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:Openssl bugfix CVE-2019-1551 Team:OTHERS Feature or Bugfix:Bugfix Binary Source:No PrivateCode(Yes/No):No Change-Id: I73aa3eb8c8f1fcbd49183ddfe3e2ea17a4c12bc5 Reviewed-on: http://mgit-tm.rnd.huawei.com/9089040Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Ndongjinguang 00268009 <dongjinguang@huawei.com> Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com>
-
- 31 5月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:use openssl asm mode Team:OTHERS Feature or Bugfix:Bugfix Binary Source:No PrivateCode(Yes/No):No Change-Id: Id449bd200b5e2ef817ac329fc6874190bc245ad4 Reviewed-on: http://mgit-tm.rnd.huawei.com/9083098Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com>
-
- 31 3月, 2020 1 次提交
-
-
由 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/11445)
-
- 19 3月, 2020 2 次提交
-
-
由 Bernd Edlinger 提交于
This should avoid half of the trial divisions in probable_prime_dh_safe and avoid bn_probable_prime_dh generating primes with special properties. Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9387)
-
由 Bernd Edlinger 提交于
Currently probable_prime makes sure that p-1 does not have any prime factors from 3..17863, which is useful for safe primes, but not necessarily for the general case. Issue was initially reported here: MIRONOV, I. Factoring RSA Moduli II. https://windowsontheory.org/2012/05/17/factoring-rsa-moduli-part-ii/Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9387)
-
- 17 3月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com> (Merged from https://github.com/openssl/openssl/pull/11344)
-
- 27 2月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:openssl 1.1.1d used bu libhapverify Team:OTHERS Feature or Bugfix:Feature Binary Source:Yes, it is PrivateCode(Yes/No):No Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com> Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>
-
- 17 2月, 2020 1 次提交
-
-
由 David Benjamin 提交于
If one of the perlasm xlate drivers crashes, OpenSSL's build will currently swallow the error and silently truncate the output to however far the driver got. This will hopefully fail to build, but better to check such things. Handle this by checking for errors when closing STDOUT (which is a pipe to the xlate driver). This is the OpenSSL 1.1.1 version of https://github.com/openssl/openssl/pull/10883 and https://github.com/openssl/openssl/pull/10930. Reviewed-by: NMark J. Cox <mark@awe.com> Reviewed-by: NPaul Dale David Benjamin <davidben@google.com> (Merged from https://github.com/openssl/openssl/pull/10931)
-
- 06 2月, 2020 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #10998 Reviewed-by: NShane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11000)
-
- 21 1月, 2020 1 次提交
-
-
由 Bernd Edlinger 提交于
Configure creates an empty crypto/include which gets not cleaned up with make distclean. Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10893)
-
- 17 1月, 2020 1 次提交
-
-
由 Richard Levitte 提交于
Fixes #10853 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10857)
-
- 02 1月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
The New Year has caused various files to appear out of date to "make update". This causes Travis to fail. Therefore we update those files. Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10739)
-
- 21 12月, 2019 2 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10652) (cherry picked from commit 013c2e8d1a272df444f47b8b54de1d51bc499887)
-
由 Bernd Edlinger 提交于
Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10651) (cherry picked from commit 0190c52ab8b4cdf5fe577b3d924576167c892a15)
-
- 06 12月, 2019 2 次提交
-
-
由 Bernd Edlinger 提交于
We have always a carry in %rcx or %rbx in range 0..2 from the previous stage, that is added to the result of the 64-bit square, but the low nibble of any square can only be 0, 1, 4, 9. Therefore one "adcq $0, %rdx" can be removed. Likewise in the ADX code we can remove one "adcx %rbp, $out" since %rbp is always 0, and carry is also zero, therefore that is a no-op. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10575)
-
由 Andy Polyakov 提交于
There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. CVE-2019-1551 Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/10575)
-
- 17 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10454) (cherry picked from commit 97a986f78289fef71bf8778dc4763458e983750c)
-
- 03 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
clang imposes some restrictions on the assembler code that gcc does not. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10330) (cherry picked from commit 6f93f06135cbbd36c3fe98d63717e8303a5d559b) Conflicts: crypto/perlasm/s390x.pm (non-existant) crypto/s390xcpuid.pl (code to be changed non-existant)
-
- 31 10月, 2019 1 次提交
-
-
由 Billy Brumley 提交于
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10209) (cherry picked from commit 305bf9c8668aff78e668131061f4eb088457be5f)
-
- 23 10月, 2019 1 次提交
-
-
由 Cesar Pereida Garcia 提交于
PR https://github.com/openssl/openssl/pull/10122 introduced changes to the BN_gcd function and the control logic inside it accessed `g->d[0]` irrespective of `g->top`. When BN_add is called, in case the result is zero, `BN_zero` is called. The latter behaves differently depending on the API compatibility level flag: normally `g->d[0]` is cleared but in `no-deprecated` builds only `g->top` is set to zero. This commit uses bitwise logic to ensure that `g` is treated as zero if `g->top` is zero, irrespective of `g->d[0]`. Co-authored-by: NNicola Tuveri <nic.tuv@gmail.com> (cherry picked from commit 8aca4bfe8213402c80abc06fe25121461f79128d) Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10232)
-
- 17 10月, 2019 2 次提交
-
-
由 Cesar Pereida Garcia 提交于
This commit replaces the current `BN_gcd` function with a constant-time GCD implementation. (cherry picked from commit f3c4adfc7eb13e9eff514039b4c60b457bdba433) Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10122)
-
由 Cesar Pereida Garcia 提交于
This commit aims at refactoring the `BN_rshift` by making it a wrapper around `bn_rshift_fixed_top`, in order to match the current design of `BN_lshift`, as suggested in the discussion at https://github.com/openssl/openssl/pull/10122#discussion_r332474277 . As described in the code, by refactoring this function, `BN_rshift` provides a constant-time behavior for sufficiently[!] zero-padded inputs under the following assumptions: `|n < BN_BITS2|` or `|n / BN_BITS2|` being non-secret. Notice that `BN_rshift` returns a canonical representation of the BIGNUM, if a `fixed_top` representation is required, the caller should call `bn_rshift_fixed_top` instead. (cherry picked from commit 8eba6de59e2b06f23c214344423a5a618d1c9ffd) Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10196)
-
- 28 9月, 2019 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Make the include guards consistent by renaming them systematically according to the naming conventions below The public header files (in the 'include/openssl' directory) are not changed in 1.1.1, because it is a stable release. For the private header files files, the guard names try to match the path specified in the include directives, with all letters converted to upper case and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
由 Dr. Matthias St. Pierre 提交于
Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
由 Dr. Matthias St. Pierre 提交于
Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
- 10 9月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9847)
-
- 07 9月, 2019 3 次提交
-
-
由 Nicola Tuveri 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511) (cherry picked from commit 1b338abe3abb8c73f004c34d4b8a9272b89dfd5d)
-
由 Nicola Tuveri 提交于
This issue was partially addressed by commit 972c87df, which hardened its callee BN_num_bits_word() to avoid leaking the most-significant word of its argument via branching and memory access pattern. The commit message also reported: > There are a few places where BN_num_bits is called on an input where > the bit length is also secret. This does *not* fully resolve those > cases as we still only look at the top word. BN_num_bits() is called directly or indirectly (e.g., through BN_num_bytes() or BN_bn2binpad() ) in various parts of the `crypto/ec` code, notably in all the currently supported implementations of scalar multiplication (in the generic path through ec_scalar_mul_ladder() as well as in dedicated methods like ecp_nistp{224,256,521}.c and ecp_nistz256.c). Under the right conditions, a motivated SCA attacker could retrieve the secret bitlength of a secret nonce through this vulnerability, potentially leading, ultimately, to recover a long-term secret key. With this commit, exclusively for BIGNUMs that are flagged with BN_FLG_CONSTTIME, instead of accessing only bn->top, all the limbs of the BIGNUM are accessed up to bn->dmax and bitwise masking is used to avoid branching. Memory access pattern still leaks bn->dmax, the size of the lazily allocated buffer for representing the BIGNUM, which is inevitable with the current BIGNUM architecture: reading past bn->dmax would be an out-of-bound read. As such, it's the caller responsibility to ensure that bn->dmax does not leak secret information, by explicitly expanding the internal BIGNUM buffer to a public value sufficient to avoid any lazy reallocation while manipulating it: this should be already done at the top level alongside setting the BN_FLG_CONSTTIME. Thanks to David Schrammel and Samuel Weiser for reporting this issue through responsible disclosure. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9511) (cherry picked from commit 8b44198b916015f77bef1befa26edb48ad8a0238)
-
由 Bernd Edlinger 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/9782) (cherry picked from commit 31ca19403d56ad71d823cf62990518dfc6905bb4)
-
- 01 8月, 2019 1 次提交
-
-
由 Antoine Cœur 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NShane Lontis <shane.lontis@oracle.com> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/9295)
-
- 23 7月, 2019 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9438) (cherry picked from commit 82925f9dd0492f2e5f1d80ff46fd59f0704c8fe6)
-
- 07 7月, 2019 1 次提交
-
-
由 Bernd Edlinger 提交于
Happens when trying to generate 4 or 5 bit safe primes. [extended tests] Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9311) (cherry picked from commit 291f616ced45c924d639d97fc9ca2cbeaad096cf)
-
- 11 6月, 2019 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NShane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9123) (cherry picked from commit e98e586b31386af2b2212729da85561a207e7af3)
-
- 28 5月, 2019 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9034)
-
- 19 3月, 2019 2 次提交
-
-
由 Hua Zhang 提交于
There are some compiling errors for mips32r6 and mips64r6: crypto/bn/bn-mips.S:56: Error: opcode not supported on this processor: mips2 (mips2) `mulu $1,$12,$7' crypto/mips_arch.h: Assembler messages: crypto/mips_arch.h:15: Error: junk at end of line, first unrecognized character is `&' Signed-off-by: NHua Zhang <hua.zhang1974@hotmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8464) (cherry picked from commit 1b9c5f2e2f283a3b12d02a89c11b8e8d97bc6312)
-
由 Richard Levitte 提交于
Fixes #8495 Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8496) (cherry picked from commit 2864df8f9d3264e19b49a246e272fb513f4c1be3)
-