- 20 2月, 2020 3 次提交
-
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11063)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11063)
-
由 Dane (4cad@silvertoque) 提交于
https://github.com/openssl/openssl/issues/10958 CLA: trivial Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11125)
-
- 19 2月, 2020 10 次提交
-
-
由 Simon Cornish 提交于
Allow for encryption overhead in early DTLS size check and send overflow if validated record is too long Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11096)
-
由 Nicola Tuveri 提交于
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/10631)
-
由 Nicola Tuveri 提交于
`BN_copy()` (and indirectly `BN_dup()`) do not propagate the `BN_FLG_CONSTTIME` flag: the propagation has been turned on and off a few times in the past years, because in some conditions it has shown unintended consequences in some code paths. Without turning the propagation on once more, we can still improve `BN_copy()` by avoiding to leak `src->top` in case `src` is flagged with `BN_FLG_CONSTTIME`. In this case we can instead use `src->dmax` as the number of words allocated for `dst` and for the `memcpy` operation. Barring compiler or runtime optimizations, if the caller provides `src` flagged as const time and preallocated to a public size, no leak should happen due to the copy operation. 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/10631)
-
由 Nicola Tuveri 提交于
We should never leak the bit length of the secret scalar in the key, so we always set the `BN_FLG_CONSTTIME` flag on the internal `BIGNUM` holding the secret scalar. This is important also because `BN_dup()` (and `BN_copy()`) do not propagate the `BN_FLG_CONSTTIME` flag from the source `BIGNUM`, and this brings an extra risk of inadvertently losing the flag, even when the called specifically set it. The propagation has been turned on and off a few times in the past years because in some conditions has shown unintended consequences in some code paths, so at the moment we can't fix this in the BN layer. In `EC_KEY_set_private_key()` we can work around the propagation by manually setting the flag after `BN_dup()` as we know for sure that inside the EC module the `BN_FLG_CONSTTIME` is always treated correctly and should not generate unintended consequences. Setting the `BN_FLG_CONSTTIME` flag alone is never enough, we also have to preallocate the `BIGNUM` internal buffer to a fixed public size big enough that operations performed during the processing never trigger a realloc which would leak the size of the scalar through memory accesses. Fixed Length ------------ The order of the large prime subgroup of the curve is our choice for a fixed public size, as that is generally the upper bound for generating a private key in EC cryptosystems and should fit all valid secret scalars. For preallocating the `BIGNUM` storage we look at the number of "words" required for the internal representation of the order, and we preallocate 2 extra "words" in case any of the subsequent processing might temporarily overflow the order length. Future work ----------- A separate commit addresses further hardening of `BN_copy()` (and indirectly `BN_dup()`). 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/10631)
-
由 Nicola Tuveri 提交于
For EC keys it is particularly important to avoid leaking the bit length of the secret scalar. Key import/export should never leak the bit length of the secret scalar in the key. For this reason, on export we use padded BIGNUMs with fixed length, using the new `ossl_param_bld_push_BN_pad()`. When importing we also should make sure that, even if short lived, the newly created BIGNUM is marked with the BN_FLG_CONSTTIME flag as soon as possible, so that any processing of this BIGNUM might opt for constant time implementations in the backend. Setting the BN_FLG_CONSTTIME flag alone is never enough, we also have to preallocate the BIGNUM internal buffer to a fixed size big enough that operations performed during the processing never trigger a realloc which would leak the size of the scalar through memory accesses. Fixed length ------------ The order of the large prime subgroup of the curve is our choice for a fixed public size, as that is generally the upper bound for generating a private key in EC cryptosystems and should fit all valid secret scalars. For padding on export we just use the bit length of the order converted to bytes (rounding up). For preallocating the BIGNUM storage we look at the number of "words" required for the internal representation of the order, and we preallocate 2 extra "words" in case any of the subsequent processing might temporarily overflow the order length. Future work ----------- To ensure the flag and fixed size preallocation persists upon `EC_KEY_set_private_key()`, we need to further harden `EC_KEY_set_private_key()` and `BN_copy()`. This is done in separate commits. 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/10631)
-
由 Nicola Tuveri 提交于
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/10631)
-
由 Nicola Tuveri 提交于
Current CMS en/decryption tests only validate that our current decyption and encryption algorithms are compatible, but they say nothing about correctness of the output for the given set of parameters. As a partial fix in absence of proper KAT tests, we decrypt ciphertexts generated with OpenSSL 1.1.1. 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/10631)
-
由 Nicola Tuveri 提交于
A pair of internal functions related to EC_KEY handling could benefit from declaring `EC_KEY *` variables as `const`, providing clarity for callers and readers of the code, in addition to enlisting the compiler in preventing some mistakes. 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/10631)
-
由 Nicola Tuveri 提交于
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/10631)
-
由 H.J. Lu 提交于
Since pointer in x32 is 4 bytes, add x86_64-support.pl to define pointer_size and pointer_register based on flavour to support stuctures like: struct { void *ptr; int blocks; } This fixes 90-test_sslapi.t on x32. Verified with $ ./Configure shared linux-x86_64 $ make $ make test and $ ./Configure shared linux-x32 $ make $ make test Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10988)
-
- 18 2月, 2020 26 次提交
-
-
由 Alex Boboc 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11104)
-
由 Alex Boboc 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11104)
-
由 Alex Boboc 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11104)
-
由 Alex Boboc 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11104)
-
由 Alex Boboc 提交于
CLA: trivial Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11104)
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11106)
-
由 Richard Levitte 提交于
test/generate_ssl_tests.pl uses OpenSSL::Test to get to some of its practical location functions. A recent note in the setup() code made its result not quite match the original (we do check that), so there's a need to silence setup(), which we do with a simple optional argument. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
We had all tests run with test/test-runs/ as working directory, and tests cleaned up after themselves... which is well and good, until you want to have a look at what went wrong when a complex test fails, and you have to recreate everything it does manually. To remedy this, we have OpenSSL::Test create the result directory dynamically (and cleaning it up first if it's already there) and let the test recipe have that as working directory. Test recipes are now encouraged to name their diverse output files uniquely, and not to clean them up, to allow a developer to have a look at the files that were produced. With continuous integration that allows this, the result directories could also be archived and be left as a build artifact. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11080)
-
由 Richard Levitte 提交于
Most of all, the base X509_LOOKUP functionality is now documented. Furthermore, the names X509_LOOKUP_METHOD and X509_STORE are added for reference. Some functions were moved from X509_LOOKUP_meth_new.pod Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10986)
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11045)
-
由 Richard Levitte 提交于
Because we generate an increasing number of POD files, some of them end up in the build tree. This makes it difficult for find-doc-nits to work as desired when the build tree is separate from the source tree. The best supported way to make it work in such an environment is to run it from the build tree and let it use the build information from configdata.pm to find all the POD files. To make this smooth enough, we add a function 'files' that returns an array of file names corresponding to criteria from the caller. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11045)
-
- 17 2月, 2020 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11101)
-