Otherwise commands like openssl req -newkey sm2 fail silently without
reporting any error unless -sm3 option is added.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16833)
The GCM mode of the SM4 algorithm is specifieded by RFC8998.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16491)
This is adding robustness to the code. The fix to not mis-set the pointer
is in #16636.
Fixes#16631
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16640)
Since EncryptedPrivateKeyInfo is a recognised structure, it's
reasonable to think that someone might want to specify it.
To be noted is that if someone specifies the structure PrivateKeyInfo
but has also passed a passphrase callback, the result will still
become a EncryptedPrivateKeyInfo structure.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
When the user expects to load a certificate or a CRL through the
OSSL_STORE loading function, the 'file:' implementation sets the
corresponding structure names in the internal decoder context.
This is especially geared for PEM files, which often contain a mix of
objects, and password prompting should be avoided for objects that
need them, but aren't what the caller is looking for.
Fixes#16224
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
The data structure wasn't given for recognised certificates or CRLs.
It's better, though, to specify it for those objects as well, so they
can be used to filter what actually gets decoded, which will be
helpful for our OSSL_STORE 'file:' scheme implementation.
Fixes#16224
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
The x86_64 cross compiler says that 'unsigned long long' isn't the
same as 'unsigned __int64'. Sure, and considering that
providers/implementations/rands/seeding/rand_vms.c is specific VMS
only code, it's easy to just change the type to the exact same as
what's specified in the system headers.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16497)
(cherry picked from commit 1ef526ef42)
The AES wrap cipher was return -1 on error from the provider rather than 0.
This is fixed.
There was a problem with the error handling in AES wrap which fell back to a
default "final error". This adds a fix for the error and more specific errors
for the different failure possibilities.
Fixes#16387
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16391)
Previously the length of the SM2 plaintext could be incorrectly calculated.
The plaintext length was calculated by taking the ciphertext length and
taking off an "overhead" value.
The overhead value was assumed to have a "fixed" element of 10 bytes.
This is incorrect since in some circumstances it can be more than 10 bytes.
Additionally the overhead included the length of two integers C1x and C1y,
which were assumed to be the same length as the field size (32 bytes for
the SM2 curve). However in some cases these integers can have an additional
padding byte when the msb is set, to disambiguate them from negative
integers. Additionally the integers can also be less than 32 bytes in
length in some cases.
If the calculated overhead is incorrect and larger than the actual value
this can result in the calculated plaintext length being too small.
Applications are likely to allocate buffer sizes based on this and therefore
a buffer overrun can occur.
CVE-2021-3711
Issue reported by John Ouyang.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Adding KRB5 test vector 'NextIV' values to evp_test data for AES CTS indicated that the CTS decrypt functions incorrectly returned the wrong IV. The returned IV should match the value returned by the encrypt methods.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16286)
The include is added before <CommonCrypto/CommonRandom.h>,
as required by older releases of the macOS developer tools.
Fixes#16248
CLA: trivial
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16258)
encode_key2text.c(689): error C4703: potentially uninitialized local pointer variable 'modulus_label' used
encode_key2text.c(691): error C4703: potentially uninitialized local pointer variable 'exponent_label' used
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12845)
This function needs to be power up tested as part of the FIPS validation and
thus it needs to be inside the provider boundary. This is realised by
introducing a new KDF "TLS13-KDF" which does the required massaging of
parameters but is otherwise functionally equivalent to HKDF.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/16203)
Word from the lab is:
The use of the derivation function is optional if either an approved
RBG or an entropy source provides full entropy output when entropy
input is requested by the DRBG mechanism. Otherwise, the derivation
function shall be used.
So our disallowing it's use was more than required.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/16096)
The flag_allow_md prevents setting a digest in params however
this is unnecessarily strict. If the digest is the same as the
one already set, we do not return an error.
Fixes#16071
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16076)
Fix memory leak if legacy test is skipped.
Using EVP_KDF_CTX_get_params() to get OSSL_KDF_PARAM_SIZE will now
return 0 if the returned size is 0.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15977)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15974)
The 'file:' store loader only understood DER natively. With all the
whatever to key decoders gone, direct support for other binary file
formats are gone, and we need to recreate them for this store loader.
With these changes, it now also understands MSBLOB and PVK files.
As a consequence, any store loader that handles some form of open file
data (such as a PEM object) can now simply pass that data back via
OSSL_FUNC_store_load()'s object callback. As long as libcrypto has
access to a decoder that can understand the data, the appropriate
OpenSSL object will be generated for it, even if the store loader sits
in a different provider than any decoder or keymgmt.
For example, an LDAP store loader, which typically finds diverse PEM
formatted blobs in the database, can simply pass those back via the
object callback, and let libcrypto do the rest of the work.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15981)
This makes the 'file:' store loader only read the file, and only decode
down to a base level binary format, and simply pass that blob of data
back to the OSSL_FUNC_store_load() object callback.
This offloads the decoding into specific OpenSSL types to libcrypto,
which takes away the issue of origins, which provider is it that holds
the key (or other future types of objects).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15981)
When decoding a key and asking the keymgmt to import the key data, it
was told that the key data includes everything. This may not be true,
since the user may have specified a different selection, and some
keymgmts may want to be informed.
Our key decoders' export function, on the other hand, didn't care
either, and simply export anything they could, regardless.
In both cases, the selection that was specified by the user is now
passed all the way.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15934)
This is to avoid creating confusion where other PEM decoder
implementations may know better what PEM names that are unknown to us
actually mean.
Fixes#15929
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15930)
Previously all the SubjectPublicKeyInfo decoders were specific to a key
type. We would iterate over all them until a match was found for the correct
key type. Each one would fully decode the key before then testing whether
it was a match or not - throwing it away if not. This was very inefficient.
Instead we introduce a generic SubjectPublicKeyInfo decoder which figures
out what type of key is contained within it, before subsequently passing on
the data to a key type specific SubjectPublicKeyInfo decoder.
Fixes#15646
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15662)
This has us switch from the 'structure' "pkcs8" to "PrivateKeyInfo",
which is sensible considering we already have "SubjectPublicKeyInfo".
We also add "EncryptedPrivateKeyInfo", and use it for a special decoder
that detects and decrypts an EncryptedPrivateKeyInfo structured DER
blob into a PrivateKeyInfo structured DER blob and passes that on to
the next decoder implementation.
The result of this change is that PKCS#8 decryption should only happen
once per decoding instead of once for every expected key type.
Furthermore, this new decoder implementation sets the data type to the
OID of the algorithmIdentifier field, thus reducing how many decoder
implementations are tentativaly run further down the call chain.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15498)
Allocate at least one byte to distinguish a zero length key
from an unset key.
Fixes#15632
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15643)
Systems such as Tru64 ship with broken headers that
have _POSIX_TIMERS defined but empty.
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15598)
Fixes#15531
DES and TDES set this flag which could possibly be used by applications.
The gettable cipher param OSSL_CIPHER_PARAM_HAS_RAND_KEY has been added.
Note that EVP_CIPHER_CTX_rand_key() uses this flag.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15606)
Fixes#15548
Document OSSL_PKEY_PARAM_EC_PUB_X, OSSL_PKEY_PARAM_EC_PUB_Y and OSSL_PKEY_PARAM_DEFAULT_DIGEST
Added a section related to parameters for SM2.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15601)
Various different initialization sequences led to bugs on s390x due to caching
and processing during key setting. Since, e.g., the direction does not
necessarily have to be correct during initialization, this produced bugs in
s390x which were not present on other architectures. Fix this by recomputing
the function codes on the fly during updates and final operations.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15521)
They aren't needed at all any more, since the properties contain the
same information.
This also drops the parameter names OSSL_ENCODER_PARAM_OUTPUT_TYPE
and OSSL_ENCODER_PARAM_OUTPUT_STRUCTURE
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
This was a poor substitute for using the name of the decoder implementation,
and since there is functionality to get the latter now, this parameter
can be dropped.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
