This is defined in NIST SP 800-208 as the truncation to 192 bits of
SHA256. Unlike other truncated hashes in the SHA2 suite, this variant
doesn't have a different initial state, it is just a pure truncation
of the output.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21180)
We split the page into two: one covering basic TLS introductory material
that applies to both clients and servers, and one with the specific
material on writing a blocking TLS client.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21133)
Provide guidance on the steps needed to write a very simple blocking TLS
client.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21133)
With 3.0.8 validated, we need to note this in the documentation.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21049)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20879)
Fix only typos in doc/man* for inclusion in 3.* branches.
Other typos have been fixed in a different commit.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20924)
Links were missing starting tags
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20729)
Also updated the corresponding documentations.
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)
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/20741)
CLA: trivial
The functions that should be implemented together are `OSSL_FUNC_signature_verify_recover_init` and `OSSL_FUNC_signature_verify_recover` and not `OSSL_FUNC_signature_verify_recover_init` with ` OSSL_FUNC_signature_verify_init`
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20704)
CLA: trivial
The thing created by `OSSL_FUNC_signature_newctx()` and `OSSL_FUNC_signature_dupctx()` is a signature context, not a signature. It's in the name of the function and surrounding documentation.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20705)
The documentation didn't mention the development where EVP_PKEY_get_id()
returns a negative value for provider-only implementations, and the
migration guide didn't mention how to cope with that.
Fixes#20497
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20501)
The documented return type of the (incorrectly named; see below) OSSL_FUNC_decoder_export_object function signature is wrong; the correct type is int, due to the following line in core_dispatch.h:
OSSL_CORE_MAKE_FUNC(int, decoder_export_object,
Fixes#19543
Per the Github conversation with levitte and t8m for pull request #19964, the following issues are not addressed by this patch:
The macro OSSL_CORE_MAKE_FUNC in core_dispatch.h generates a function, and a corresponding function signature typedef with name ending in "_fn". The typedefed signature is unrelated to the signature of the function.
However, provider-decoder.pod describes typedefed signatures generated by the macro, but uses the names of the functions (lacking "_fn") instead of the typedefed signatures, which is a mismatch.
Also, the documented claim about OSSL_FUNC_decoder_export_object, etc that "None of these are actual functions" is contradicted by the fact that the code actually calls those functions, and calls them specifically by those names. E.g. in decoder_meth.c:
decoder->export_object = OSSL_FUNC_decoder_export_object(fns);
The functions are generated by OSSL_CORE_MAKE_FUNC.
The paragraph "None of these are actual functions"... should be replaced by something more like "These function signatures, generated by the OSSL_CORE_MAKE_FUNC macro, are for functions that are offered via function pointers in OSSL_DISPATCH arrays."
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19964)
This describes them in detail in provider-keymgmt(7).
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20430)
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)
This was in the notes section but an earlier comment about it not being
mandatory was missed.
Fixes#20376
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20382)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20361)
Clearly document that implicit fetching is slower when using providers,
and explain prefetching. Added to crypto.pod and migration_guide.pod
links to it.
Add a link to EVP_default_properties_enable_fips() in crypto.pod.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20354)
The provider functions OSSL_FUNC_keymgmt_import_types() and
OSSL_FUNC_keymgmt_export_types() do not get the provider context passed.
This makes it difficult for providers to implement these functions unless
its a static implementation returning a truly constant OSSL_PARAM array.
Some providers may have a need to return an OSSL_PARAM array that is
dependent on the provider configuration, or anything else that is contained
in its provider context.
Add extended variants of these functions that get the provider context passed.
The functions should still return a static and constant OSSL_PARAM array, but
may use the provider context to select the array to return dependent on its
context. The returned array must be constant at least until the provider is
unloaded.
Providers can implement only the original functions, or only the extended
functions, or both. Implementing at least one of those functions is required
if also the respective OSSL_FUNC_keymgmt_import() or OSSL_FUNC_keymgmt_export()
function is implemented. If an extended function is available, it is called by
evp_keymgmt_import_types() or evp_keymgmt_export_types(), otherwise the original
function is called.
This makes the code backward compatible. Existing providers will only implement
the original functions, so these functions will continued to be called.
Newer providers can choose to implement the extended functions, and thus can
benefit from the provider context being passed to the implementation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20255)
https://github.com/openssl/openssl/pull/19901 backported the
"Honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set and default to
UNCOMPRESSED" changeset to 3.0.
This commit updates:
- the HISTORY notes of the relevant documentation to mark the change
happened since 3.0.8.
- the `CHANGES.md file` to sync up with the tip of the `openssl-3.0`
branch
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20003)
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)
The lab tried doing a RSA decryption primitive using just n (using p, q) and d.
This failed for 2 reasons:
(1) e is required when importing
(2) Internally e is used for blinding.
Note n and e can be calculated using:
n = pq
e = (1/d) mod (p-1)(q-1)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20133)
Ed25519 and Ed448 are included in the FIPS 140-3 provider for
compatibility purposes but are flagged as "fips=no" to prevent their accidental
use. This therefore requires that applications always specify the "fips=yes"
property query to enforce FIPS correctness.
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)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20023)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20023)
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)
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)
Fixes#19953
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20008)
Fixes#19782
Clarify that EVP_Q_MAC() can be used as an alternative that allows
setting of the libctx.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19855)
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)
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM,
OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own
manual page, so we change every mention of them to links to those pages.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19842)
This expands on some of the core type descriptions, and also makes it
easier to find the documentation for each type, at least on Unix, with
a simple call like "man OSSL_ALGORITHM".
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19842)
parameter.
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/18809)
This PR is based off the contributions in PR #9223 by Jemmy1228.
It has been modified and reworked to:
(1) Work with providers
(2) Support ECDSA and DSA
(3) Add a KDF HMAC_DRBG implementation that shares code with the RAND HMAC_DRBG.
A nonce_type is passed around inside the Signing API's, in order to support any
future deterministic algorithms.
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/18809)
