- 12 2月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
Add ref counting and control how we allocate storage for the private key. We will need this type in following commits where we move the ecx code to be provider aware. Reviewed-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NShane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10964)
-
- 06 2月, 2020 1 次提交
-
-
由 Pauli 提交于
It is better, safer and smaller to let the library routine handle the strlen(3) call. Added a note to the documentation suggesting this. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11019)
-
- 04 2月, 2020 2 次提交
-
-
由 Pauli 提交于
Use of the low level ECDSA and EC_KEY_METHOD functions has been informally discouraged for a long time. We now formally deprecate them. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10960)
-
由 Pauli 提交于
Use of the low level ECDH functions has been informally discouraged for a long time. We now formally deprecate them. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10960)
-
- 02 2月, 2020 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10942)
-
- 23 1月, 2020 2 次提交
-
-
由 Shane Lontis 提交于
Added comments and cleared an intermediate result. KAT tests already exist in evppkey.txt (Search for "KAS_ECC_CDH_PrimitiveTest") Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10838)
-
由 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). Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10883)
-
- 19 1月, 2020 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10791)
-
- 17 1月, 2020 1 次提交
-
-
由 Richard Levitte 提交于
Fixes #10853 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10855)
-
- 07 1月, 2020 1 次提交
-
-
由 Shane Lontis 提交于
ECDSA signature lengths are calculated using i2d_ECDSA_SIG(). i2d_ECDSA_SIG() was changed in a previous PR to use a custom ASN1 encoder (using WPACKET) so that the normal ASN1 encoder does not need to be pulled into the provider boundary. For consistency ECDSA_size() has been changed to also use i2d_ECDSA_SIG() - this can now be used directly inside the FIPS provider. Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10577)
-
- 05 1月, 2020 8 次提交
-
-
由 Andrew Hoang 提交于
ECDSA_do_verify() is a function that verifies a ECDSA signature given a hash and a public EC key. The function is supposed to return 1 on valid signature, 0 on invalid signature and -1 on error. Previously, we returned 0 if the key did not have a verify_sig method. This is actually an error case and not an invalid signature. Consequently, this patch updates the return code to -1. Fixes #8766 Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10693)
-
由 Fangming.Fang 提交于
This change addresses a potential side-channel vulnerability in the internals of nistz256 low level operations for armv8. Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 Bernd Edlinger 提交于
This is only used if configured with ./config -DECP_NISTZ256_REFERENCE_IMPLEMENTATION Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 Bernd Edlinger 提交于
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 Bernd Edlinger 提交于
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 Bernd Edlinger 提交于
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 David Benjamin 提交于
Cherry picked from https://github.com/google/boringssl/commit/12d9ed670da3edd64ce8175cfe0e091982989c18Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9239)
-
由 Nicola Tuveri 提交于
This commit addresses a potential side-channel vulnerability in the internals of some elliptic curve low level operations. The side-channel leakage appears to be tiny, so the severity of this issue is rather low. The issue was reported by David Schrammel and Samuel Weiser. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9239)
-
- 24 12月, 2019 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10676)
-
- 23 12月, 2019 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10672)
-
- 21 11月, 2019 1 次提交
-
-
由 Pauli 提交于
Verifications are public, there is no need to clear the used storage before freeing it. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10475)
-
- 14 11月, 2019 1 次提交
-
-
由 Nicola Tuveri 提交于
EC_POINT_bn2point() rejected BIGNUMs with a zero value. This behavior indirectly caused failures when converting a point at infinity through EC_POINT_point2hex() and then back to a point with EC_POINT_hex2point(). With this change such BIGNUMs are treated like any other and exported to an octet buffer filled with zero. It is then EC_POINT_oct2point() (either the default implementation or the custom one in group->meth->oct2point) to determine if such encoding maps to a valid point (generally the point at infinity is encoded as 0x00). Fixes #10258 Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10329)
-
- 07 11月, 2019 1 次提交
-
-
由 Richard Levitte 提交于
Previous macros suggested that from 3.0, we're only allowed to deprecate things at a major version. However, there's no policy stating this, but there is for removal, saying that to remove something, it must have been deprecated for 5 years, and that removal can only happen at a major version. Meanwhile, the semantic versioning rule is that deprecation should trigger a MINOR version update, which is reflected in the macro names as of this change. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
-
- 05 11月, 2019 2 次提交
-
-
由 Patrick Steuer 提交于
...in constant time. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10339)
-
由 Patrick Steuer 提交于
The s390x x448 implementation does not correctly reduce non-canonical values i.e., u-coordinates >= p = 2^448 - 2^224 - 1. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10339)
-
- 02 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
ecp_s390x_nistp.c and ecx_meth.c need to include s390x_arch.h. 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/10317)
-
- 23 10月, 2019 2 次提交
-
-
由 Nicola Tuveri 提交于
There is nothing confidential in `EC_GROUP` so really having a `EC_GROUP_clear_free` function at all does not make much sense anymore. See https://github.com/openssl/openssl/issues/9822Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9874)
-
由 Nicola Tuveri 提交于
There is nothing confidential in `EC_GROUP` so really having a `EC_GROUP_clear_free` function at all does not make much sense anymore. See https://github.com/openssl/openssl/issues/9822Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9874)
-
- 16 10月, 2019 1 次提交
-
-
由 Shane Lontis 提交于
Implementations are now spread across several libraries, so the assembler related defines need to be applied to all affected libraries and modules. AES_ASM define was missing from libimplementations.a which disabled AESNI aarch64 changes were made by xkqian. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10180)
-
- 15 10月, 2019 1 次提交
-
-
由 Nicola Tuveri 提交于
An unintended consequence of https://github.com/openssl/openssl/pull/9808 is that when an explicit parameters curve is matched against one of the well-known builtin curves we automatically inherit also the associated seed parameter, even if the input parameters excluded such parameter. This later affects the serialization of such parsed keys, causing their input DER encoding and output DER encoding to differ due to the additional optional field. This does not cause problems internally but could affect external applications, as reported in https://github.com/openssl/openssl/pull/9811#issuecomment-536153288 This commit fixes the issue by conditionally clearing the seed field if the original input parameters did not include it. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10140)
-
- 10 10月, 2019 2 次提交
-
-
由 Richard Levitte 提交于
We put almost everything in these internal static libraries: libcommon Block building code that can be used by all our implementations, legacy and non-legacy alike. libimplementations All non-legacy algorithm implementations and only them. All the code that ends up here is agnostic to the definitions of FIPS_MODE. liblegacy All legacy implementations. libnonfips Support code for the algorithm implementations. Built with FIPS_MODE undefined. Any code that checks that FIPS_MODE isn't defined must end up in this library. libfips Support code for the algorithm implementations. Built with FIPS_MODE defined. Any code that checks that FIPS_MODE is defined must end up in this library. The FIPS provider module is built from providers/fips/*.c and linked with libimplementations, libcommon and libfips. The Legacy provider module is built from providers/legacy/*.c and linked with liblegacy, libcommon and libcrypto. If module building is disabled, the object files from liblegacy and libcommon are added to libcrypto and the Legacy provider becomes a built-in provider. The Default provider module is built-in, so it ends up being linked with libimplementations, libcommon and libnonfips. For libcrypto in form of static library, the object files from those other libraries are simply being added to libcrypto. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10088)
-
由 Rich Salz 提交于
Also added blanks lines after declarations in a couple of places. Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9916)
-
- 29 9月, 2019 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Make the include guards consistent by renaming them systematically according to the naming conventions below For the public header files (in the 'include/openssl' directory), the guard names try to match the path specified in the include directives, with all letters converted to upper case and '/' and '.' replaced by '_'. For the private header files files, an extra 'OSSL_' is added as prefix. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
-
由 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/9333)
-
由 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/9333)
-
- 25 9月, 2019 2 次提交
-
-
由 Patrick Steuer 提交于
using PCC and KDSA instructions. 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/10004)
-
由 Patrick Steuer 提交于
of instruction parameter blocks. 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/10004)
-
- 16 9月, 2019 3 次提交
-
-
由 Richard Levitte 提交于
They now generally conform to the following argument sequence: script.pl "$(PERLASM_SCHEME)" [ C preprocessor arguments ... ] \ $(PROCESSOR) <output file> However, in the spirit of being able to use these scripts manually, they also allow for no argument, or for only the flavour, or for only the output file. This is done by only using the last argument as output file if it's a file (it has an extension), and only using the first argument as flavour if it isn't a file (it doesn't have an extension). While we're at it, we make all $xlate calls the same, i.e. the $output argument is always quoted, and we always die on error when trying to start $xlate. There's a perl lesson in this, regarding operator priority... This will always succeed, even when it fails: open FOO, "something" || die "ERR: $!"; The reason is that '||' has higher priority than list operators (a function is essentially a list operator and gobbles up everything following it that isn't lower priority), and since a non-empty string is always true, so that ends up being exactly the same as: open FOO, "something"; This, however, will fail if "something" can't be opened: open FOO, "something" or die "ERR: $!"; The reason is that 'or' has lower priority that list operators, i.e. it's performed after the 'open' call. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9884)
-
由 Richard Levitte 提交于
Since the arguments are now generated in the build file templates, they should be removed from the build.info files. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9884)
-
由 ManishPatidar1 提交于
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9830)
-