Fixes#20710
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20745)
Cache the fetched MAC and MD implementation until propq changes.
No need to keep the output stored in the context.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20534)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20751)
Discovered during coverage testing.
Remove unneccesary check when using ossl_dh_get0_params() and
ossl_dsa_get0_params(). These point to addresses and can not fail
for any existing calls.
Make dsa keygen tests only available in the FIPS module - as they are
not used in the default provider.
Change ossl_ffc_set_digest() to return void as it cannot fail.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20359)
Add option for restricting digests available to DRBGs.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20521)
With less than C99 compilers, this macro isn't guaranteed to exist, and
the value passed to it is 32 bits, so explicitly ending it with 'UL' is
correct in all cases. We simply leave it to the compiler to extend it
appropriately for uint64_t.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20547)
Fix use after free error.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/20528)
<stdint.h> may not exist with pre-C99 compilers. <openssl/e_os2.h> deals
with that, so include it instead.
Similarly, include "internal/numbers.h" rather than <limits.h>, to deal
with things that may be lacking in the latter.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20537)
Signed-off-by: Čestmír Kalina <ckalina@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12256)
Signed-off-by: Čestmír Kalina <ckalina@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12256)
In RISC-V we have multiple extensions, that can be
used to accelerate processing.
The known extensions are defined in riscv_arch.def.
From that file test functions of the following
form are generated: RISCV_HAS_$ext().
In recent commits new ways to define the availability
of these test macros have been defined. E.g.:
#define RV32I_ZKND_ZKNE_CAPABLE \
(RISCV_HAS_ZKND() && RISCV_HAS_ZKNE())
[...]
#define RV64I_ZKND_ZKNE_CAPABLE \
(RISCV_HAS_ZKND() && RISCV_HAS_ZKNE())
This leaves us with two different APIs to test capabilities.
Further, creating the same macros for RV32 and RV64 results
in duplicated code (see example above).
This inconsistent situation makes it hard to integrate
further code. So let's clean this up with the following steps:
* Replace RV32I_* and RV64I_* macros by RICSV_HAS_* macros
* Move all test macros into riscv_arch.h
* Use "AND" and "OR" to combine tests with more than one extension
* Rename include files for accelerated processing (remove extension
postfix).
We end up with compile time tests for RV32/RV64 and run-time tests
for available extensions. Adding new routines (e.g. for vector crypto
instructions) should be straightforward.
Testing showed no regressions.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20078)
CLA: trivial
When `cleanup_entropy()` is called to cleanup parent by calling
provided `OSSL_FUNC_rand_clear_seed_fn` method, incorrect random
context is passed to the method. So accessing that context creates
a segmentation fault. Parent context should be passed rather than
DRBG's own context.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20454)
CLA: trivial
In RSA, `(n,e)` and `(n,d)` identify public key and private key.
Modulus `n` is the common part. So I updated `rsa_has()` to validate
these pairs correctly. `OSSL_KEYMGMT_SELECT_KEYPAIR` is common part
for both public and private key, so I changed it to check `n` of
RSA and for `OSSL_KEYMGMT_SELECT_PUBLIC_KEY`, `e` is checked. Before
this change, if `selection` was `OSSL_KEYMGMT_SELECT_PRIVATE_KEY` and
only `e` and `d` was in the RSA structure, the function returns 1
while it was incorrect.
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/20455)
since this code is also under GCM_HW_SET_KEY_CTR_FN macro
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/20491)
NIST SP 800-132 [1] section 5.1 says "[t]he length of the
randomly-generated portion of the salt shall be at least
128 bits", which implies that the salt for PBKDF2 must be at least 16
bytes long (see also Appendix A.2.1).
The FIPS 140-3 IG [2] section 10.3.A requires that "the lengths and the
properties of the Password and Salt parameters, as well as the desired
length of the Master Key used in a CAST shall be among those supported
by the module in the approved mode."
As a consequence, the salt length in the self test must be at least 16
bytes long for FIPS 140-3 compliance. Switch the self test to use the
only test vector from RFC 6070 that uses salt that is long enough to
fulfil this requirement. Since RFC 6070 does not provide expected
results for PBKDF2 with HMAC-SHA256, use the output from [3], which was
generated with python cryptography, which was tested against the RFC
6070 vectors with HMAC-SHA1.
[1]: https://doi.org/10.6028/NIST.SP.800-132
[2]: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
[3]: https://github.com/brycx/Test-Vector-Generation/blob/master/PBKDF2/pbkdf2-hmac-sha2-test-vectors.md
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20429)
The keccak XOF used for KMAC can be simplified by using klmd. This speeds up
XOF processing in cases where more than one result block is needed.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20431)
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/20386)
According to the documentation and my analysis tool RSA_public_decrypt()
can return -1 on error, but this is not checked. Fix it by changing the
error condition.
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20250)
This reverts commit 09627a8ceb.
NIST isn't allowing EdDSA at this stage after all, so flag it as not
FIPS approved in the FIPS provider. Guidance for FIPS 140-3 is expected
later this month:
The use of EdDSA still remains non-approved.
Before the FIPS 186-5 and SP 800-186 algorithms / curves can be
used in the approved mode, the CMVP will need to do (at least)
the following:
* Incorporate FIPS 186-5 and SP 800-186 into SP 800-140C/D;
* Update IG 10.3.A to incorporate self-test requirements for the
new algorithms/curves.
* Write a new IG on this transition to clarify the issues raised in
this thread and elsewhere and provide a clear transition schedule.
The CMVP is working on all three of these items and hope to have
drafts public by the end of March.
Since security relevant changes are not permitted for new 140-2
submissions, and under the assumption that this transition away
from FIPS 186-4 algorithms will be 'soft' and not move modules to
the historical list, we do not plan on writing 140-2 guidance for
this transition.
It seems unlikely that all of these requirements will be completed before
we submit.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20343)
kbkdf_dup should use the appropriate type OSSL_FUNC_kdf_dupctx_fn.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20314)
Avoid including QUIC related stuff in the FIPS sources.
Also avoid including libssl headers in ssl3_cbc.c.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19658)
Two key 3DES only sets two keys and the random generation errors out if fewer
than three keys are required. It shouldn't.
Fixes#20212
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20224)
Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19914)
Fixes#20084
In the 3.0 provider implementation the generic code that handles IV's
only allows a 12 byte IV. Older code intentionally added the ability for
the IV to be truncated.
As this truncation is unsafe, the documentation has been updated to
state that this in no longer allowed. The code has been updated to
produce an error when the iv length is set to any value other than 12.
NOTE: It appears that this additional padding may have originated from the code
which uses a 12 byte IV, that is then passed to CHACHA which zero pads it to 16 bytes.
Note that legacy behaviour in e_chacha20_poly1305.c has not been
updated.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20151)
CMVP's answer when questioned about this being:
X448 and X25519 uses Curve448 and Curve25519, respectfully, within an
ECDH scheme. Therefore, it is possible for a key agreement scheme
that uses Curve448 and Curve25519 to be used in the approved mode
and be viewed as an allowed algorithm if requirements of Scenario
X2 of IG D.8 and IG A.2 are met (or Scenario 3 of D.F and IG C.A for
FIPS 140-3). The use of EdDSA in the approved mode is not permitted
until FIPS 186-5 is published and part of CMVP guidance.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20079)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20109)
Context parameter OSSL_SIGNATURE_PARAM_NONCE_TYPE can now also be
retrieved for ECDSA and DSA.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20070)
CPACF does not support pre-hashing. This was considered correctly for
Ed25519ph, but not for Ed448ph which lead to errors in the test_evp suite
(test vector 20 - pre-hashing without context string). Fix this by using the
non-accelerated version of Ed448 also if no context string is provided, but
pre-hashing is performed.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20067)
In EC key generation, if allocation of struct ec_gen_ctx fails, values
provided by parameters are copied into the context at represented by a NULL
pointer. To fix this, prevent copy if allocation fails.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20055)
CPACF does not directly support xofs. Emulate this by using single block
operations on an empty input block.
Fixes: affc070aab ("s390x: Optimize kmac")
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19983)
Fixes#6277
Description:
Make each of the five EdDSA instances defined in RFC 8032 -- Ed25519,
Ed25519ctx, Ed25519ph, Ed448, Ed448ph -- available via the EVP APIs.
The desired EdDSA instance is specified via an OSSL_PARAM.
All instances, except for Ed25519, allow context strings as input.
Context strings are passed via an OSSL_PARAM. For Ed25519ctx, the
context string must be nonempty.
Ed25519, Ed25519ctx, Ed448 are PureEdDSA instances, which means that
the full message (not a digest) must be passed to sign and verify
operations.
Ed25519ph, Ed448ph are HashEdDSA instances, which means that the input
message is hashed before sign and verify.
Testing:
All 21 test vectors from RFC 8032 have been added to evppkey_ecx.txt
(thanks to Shane Lontis for showing how to do that). Those 21 test
vectors are exercised by evp_test.c and cover all five instances.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/19705)
Likewise for the related ECX key exchanges.
NIST is mandating this until FIPS 186-5 is finalised.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20020)
is used.
Fixes#19934
The existing code was looking for the digest size, and then returned
zero.
The example code in EVP_KDF-SS.pod has been corrected to not use a
digest.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19935)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19985)
Fixes#19909
I have enforced a maximum bound still but it is much higher.
Note also that TLS13 still uses the 2048 buffer size.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19923)
If x and y are all NULL, then it is unnecessary to do subsequent operations.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19905)
Now that ACVP test vectors exist, support has been added for this mode.
See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf
Note that the test vectors used fairly large values for the input key
and the context, so the contraints for these has been increased from
256 to 512 bytes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19916)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13817)
