- Jul 29, 2018
-
-
Andy Polyakov authored
Problem was that Windows threads that were terminating before libcrypto was initialized were referencing uninitialized or possibly even unrelated thread local storage index. Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6799) (cherry picked from commit 80ae7285) Resolved conflicts: crypto/init.c
-
Andy Polyakov authored
Reviewed-by:
-
- Jul 27, 2018
-
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
New implementation failed to correctly reset r->neg flag. Spotted by OSSFuzz. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Originally suggested solution for "Return Of the Hidden Number Problem" is arguably too expensive. While it has marginal impact on slower curves, none to ~6%, optimized implementations suffer real penalties. Most notably sign with P-256 went more than 2 times[!] slower. Instead, just implement constant-time BN_mod_add_quick. Reviewed-by:
-
- Jul 26, 2018
-
-
Andy Polyakov authored
Note that exported functions maintain original behaviour, so that external callers won't observe difference. While internally we can now perform Montogomery multiplication on fixed-length vectors, fixed at modulus size. The new functions, bn_to_mont_fixed_top and bn_mul_mont_fixed_top, are declared in bn_int.h, because one can use them even outside bn, e.g. in RSA, DSA, ECDSA... Reviewed-by:
-
Andy Polyakov authored
The new flag marks vectors that were not treated with bn_correct_top, in other words such vectors are permitted to be zero padded. For now it's BN_DEBUG-only flag, as initial use case for zero-padded vectors would be controlled Montgomery multiplication/exponentiation, not general purpose. For general purpose use another type might be more appropriate. Advantage of this suggestion is that it's possible to back-port it... bn/bn_div.c: fix memory sanitizer problem. bn/bn_sqr.c: harmonize with BN_mul. Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> GH: #6794 (cherry picked from commit b9e54e98)
-
Kurt Roeckx authored
The old numbers where all generated for an 80 bit security level. But the number should depend on security level you want to reach. For bigger primes we want a higher security level and so need to do more tests. Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
Paul Dale <paul.dale@oracle.com> GH: #6075 Fixes: #6012 (cherry picked from commit feac7a1c)
-
Kurt Roeckx authored
This changes the security level from 100 to 128 bit. We only have 1 define, this sets it to the highest level supported for DSA, and needed for keys larger than 3072 bit. Reviewed-by:
-
- Jul 25, 2018
-
-
Rich Salz authored
Thanks to Jiecheng Wu, Zuxing Gu for the report. Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6791) (cherry picked from commit 037241bf)
-
Andy Polyakov authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/6752) (cherry picked from commit 9e4a1c3f)
-
Andy Polyakov authored
Reviewed-by:
-
- Jul 24, 2018
-
-
Richard Levitte authored
This is done by calling die again, just make sure to reset the __DIE__ handler first. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
On the same note, change the 'NASM not found' message to give specific advice on how to handle the failure. Fixes #6765 Reviewed-by:
-
- Jul 22, 2018
-
-
Andy Polyakov authored
ecp_nistz256_set_from_affine is called when application attempts to use custom generator, i.e. rarely. Even though it was wrong, it didn't affect point operations, they were just not as fast as expected. Reviewed-by:
-
Andy Polyakov authored
The ecp_nistz256_scatter_w7 function is called when application attempts to use custom generator, i.e. rarely. Even though non-x86_64 versions were wrong, it didn't affect point operations, they were just not as fast as expected. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Richard Levitte authored
Fixes #6755 Reviewed-by:
-
Richard Levitte authored
As per RFC 7292. Fixes #6665 Reviewed-by:
-
- Jul 18, 2018
-
-
Andy Polyakov authored
It was false positive, but one can as well view it as readability issue. Switch even to unsigned indices because % BN_BYTES takes 4-6 instructions with signed dividend vs. 1 (one) with unsigned. Reviewed-by:
-
- Jul 14, 2018
-
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
"Computationally constant-time" means that it might still leak information about input's length, but only in cases when input is missing complete BN_ULONG limbs. But even then leak is possible only if attacker can observe memory access pattern with limb granularity. Reviewed-by:
-
- Jul 13, 2018
-
-
Alexandre Perrin authored
Change the description for BN_hex2bn() so that it uses the same BIGNUM argument name as its prototype. CLA: trivial Reviewed-by:
-
- Jul 12, 2018
-
-
Andy Polyakov authored
Reviewed-by:
David Benjamin <davidben@google.com> (Merged from https://github.com/openssl/openssl/pull/6662) (cherry picked from commit 6c90182a)
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Trouble is that addition is postponing expansion till carry is calculated, and if addition carries, top word can be zero, which triggers assertion in bn_check_top. Reviewed-by:
-
- Jul 11, 2018
-
-
Richard Levitte authored
We need to check that __GNUC__ is defined before trying to use it. This demands a slightly different way to define DECLARE_DEPRECATED. Reviewed-by:
-
Richard Levitte authored
To avoid the possibility that someone creates rem.exe, rem.bat or rem.cmd, simply don't use it. In the cases it was used, it was to avoid empty lines, but it turns out that nmake handles those fine, so no harm done. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/6686) (cherry picked from commit 1b6a0a26)
-
Richard Levitte authored
It seems that nmake first tries to run executables on its own, and only pass commands to cmd if that fails. That means it's possible to have nmake run something like 'echo.exe' when the builtin 'echo' command was expected, which might give us unexpected results. To get around this, we create our own echoing script and call it explicitly from the nmake makefile. Fixes #6670 Reviewed-by:
-
- Jul 10, 2018
-
-
Richard Levitte authored
The reason is that we override Text::Template::append_text_to_output(), and it didn't exist before Text::Template 1.46. Fixes #6641 Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
This enables us to require module versions, and to fall back to a bundled version if the system version is too low. Reviewed-by:
-
- Jul 06, 2018
-
-
Bernd Edlinger authored
[extended tests] Reviewed-by:
-
- Jul 04, 2018
-
-
Richard Levitte authored
Fixes #6644 Reviewed-by:
-
