From: Viktor Dukhovni Date: Fri, 20 Dec 2024 01:36:09 +0000 (+1100) Subject: Remaining batch of ML-KEM-related doc updates X-Git-Tag: openssl-3.5.0-alpha1~545 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e04a604d0dbc6a50c48e21a4658afc2a6fb2d445;p=thirdparty%2Fopenssl.git Remaining batch of ML-KEM-related doc updates Reviewed-by: Matt Caswell Reviewed-by: Tim Hudson Reviewed-by: Tomas Mraz Reviewed-by: Neil Horman (Merged from https://github.com/openssl/openssl/pull/26217) --- diff --git a/doc/HOWTO/keys.txt b/doc/HOWTO/keys.txt index c4a74c54fcb..122c1b8cde0 100644 --- a/doc/HOWTO/keys.txt +++ b/doc/HOWTO/keys.txt @@ -98,8 +98,10 @@ it may be reasonable to avoid protecting it with a password, since otherwise someone would have to type in the password every time the server needs to access the key. -For X25519 and X448, it's treated as a distinct algorithm but not as one of -the curves listed with 'ecparam -list_curves' option. You can use -the following command to generate an X25519 key: +X25519, X448, Ed25519 and Ed448 are treated as distinct algorithms and not as +one of the EC curves listed with 'ecparam -list_curves' option. You can use the +following command to generate an X25519 key: openssl genpkey -algorithm X25519 -out xkey.pem + +# TODO(ML-KEM) Likewise ML-KEM once we have codecs. diff --git a/doc/designs/fips_indicator.md b/doc/designs/fips_indicator.md index 09c66fe1c53..6a557f99b82 100644 --- a/doc/designs/fips_indicator.md +++ b/doc/designs/fips_indicator.md @@ -275,8 +275,9 @@ There are a few places where we do not enforce key size that need to be addresse - DSA. Keygen and Signing are no longer approved, verify is still allowed. - ECDSA B & K curves are deprecated, but still approved according to (IG C.K Resolution 4).\ If we chose not to remove them , then we need to check that OSSL_PKEY_PARAM_USE_COFACTOR_ECDH is set for key agreement if the cofactor is not 1. -- ED25519/ED448 is now approved. -- X25519/X448 is not approved currently. keygen and keyexchange would also need an indicator if we allow it? +- ED25519 and ED448 are now approved. +- X25519 and X448 are not approved currently. keygen and keyexchange would also need an indicator if we allow them? +- ML-KEM-512/768/1024 are not yet included in the FIPS module. - RSA encryption(for key agreement/key transport) using PKCSV15 is no longer allowed. (Note that this breaks TLS 1.2 using RSA for KeyAgreement), Padding mode updates required. Check RSA KEM also. - RSA signing using PKCS1 is still allowed (i.e. signature uses shaXXXWithRSAEncryption) diff --git a/doc/internal/man7/EVP_PKEY.pod b/doc/internal/man7/EVP_PKEY.pod index 94511d76cf1..bc0455362c1 100644 --- a/doc/internal/man7/EVP_PKEY.pod +++ b/doc/internal/man7/EVP_PKEY.pod @@ -77,9 +77,9 @@ OpenSSL providers allow it for the following: =over 4 -=item DH, EC, X25519, X448: +=item DH, EC, X25519, X448, ML-KEM (512, 768 and 1024): -It's possible to set the encoded public key. This is supported in +It is possible to set the encoded public key. This is supported in particular through L. =item EC: @@ -198,7 +198,11 @@ reflected back in the provider key. =head1 SEE ALSO -L +L, +L, +L, +L, +L. =head1 COPYRIGHT diff --git a/doc/man1/openssl-genpkey.pod.in b/doc/man1/openssl-genpkey.pod.in index 32966fcd0c2..515732d52ef 100644 --- a/doc/man1/openssl-genpkey.pod.in +++ b/doc/man1/openssl-genpkey.pod.in @@ -87,6 +87,9 @@ the standard built-in ones. Valid built-in algorithm names for private key generation are RSA, RSA-PSS, EC, X25519, X448, ED25519 and ED448. +=for comment TODO(ML-KEM) Soon also ML-KEM, once we have a standard private key + format (and a PEM header name) and encoders/decoders. + Valid built-in algorithm names for parameter generation (see the B<-genparam> option) are DH, DSA and EC. @@ -138,6 +141,9 @@ algorithm can vary. The options for the OpenSSL implementations are detailed below. There are no key generation options defined for the X25519, X448, ED25519 or ED448 algorithms. +=for comment TODO(ML-KEM) Soon also ML-KEM, once we have a standard private key + format (and a PEM header name) and encoders/decoders. + =head2 RSA Key Generation Options =over 4 @@ -501,6 +507,9 @@ Generate an ED448 private key: openssl genpkey -algorithm ED448 -out xkey.pem +=for comment TODO(ML-KEM) Soon also ML-KEM, once we have a standard private key + format (and a PEM header name) and encoders/decoders. + =head1 HISTORY The ability to use NIST curve names, and to generate an EC key directly, @@ -508,6 +517,9 @@ were added in OpenSSL 1.0.2. The ability to generate X25519 keys was added in OpenSSL 1.1.0. The ability to generate X448, ED25519 and ED448 keys was added in OpenSSL 1.1.1. +=for comment TODO(ML-KEM) Soon also ML-KEM, once we have a standard private key + format (and a PEM header name) and encoders/decoders. + The B<-engine> option was deprecated in OpenSSL 3.0. =head1 COPYRIGHT diff --git a/doc/man1/openssl-pkeyutl.pod.in b/doc/man1/openssl-pkeyutl.pod.in index e10b08cd5ec..21e41354229 100644 --- a/doc/man1/openssl-pkeyutl.pod.in +++ b/doc/man1/openssl-pkeyutl.pod.in @@ -250,6 +250,11 @@ This is needed only for RSA, where B, is not the default mode, even though it is presently the only RSA KEM supported. See L and L. +=for comment TODO(ML-KEM) Add ML-KEM, once we have encoder/decoder support the + associated keys. Specifically, the private key format is yet to + be decided (may need to support two versions, the full FIPS203 + encoding or just the seed). + =item B<-kdf> I Use key derivation function I. The supported algorithms are @@ -438,6 +443,8 @@ for the B<-pkeyopt> B option. The X25519 and X448 algorithms support key derivation only. Currently there are no additional options. +=for comment TODO(ML-KEM) Likewise for ML-KEM, once we have encoders/decoders. + =head1 ED25519 AND ED448 ALGORITHMS These algorithms only support signing and verifying. OpenSSL only implements the diff --git a/doc/man3/EVP_PKEY_CTX_ctrl.pod b/doc/man3/EVP_PKEY_CTX_ctrl.pod index c275467b897..bd94c5d1607 100644 --- a/doc/man3/EVP_PKEY_CTX_ctrl.pod +++ b/doc/man3/EVP_PKEY_CTX_ctrl.pod @@ -654,9 +654,11 @@ EVP_PKEY_CTX_set_kem_op() sets the KEM operation to run. This can be set after EVP_PKEY_encapsulate_init() or EVP_PKEY_decapsulate_init() to select the kem operation. For the key types that support encapsulation and don't have the default operation, e.g. RSA, this function must be called before -EVP_PKEY_encapsulate() or EVP_PKEY_decapsulate(). The supported values for the -built-in algorithms are enumerated in L, L, -L, and L. +EVP_PKEY_encapsulate() or EVP_PKEY_decapsulate(). + +The supported parameters for the built-in algorithms are documented in +L, L, L, +L, and L. =head1 RETURN VALUES diff --git a/doc/man3/EVP_PKEY_CTX_set_params.pod b/doc/man3/EVP_PKEY_CTX_set_params.pod index 8947648ccbe..2ef2ed7734d 100644 --- a/doc/man3/EVP_PKEY_CTX_set_params.pod +++ b/doc/man3/EVP_PKEY_CTX_set_params.pod @@ -57,6 +57,7 @@ L L L L +L =head1 RETURN VALUES @@ -84,6 +85,8 @@ L All functions were added in OpenSSL 3.0. +Support for B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/EVP_PKEY_decapsulate.pod b/doc/man3/EVP_PKEY_decapsulate.pod index 3bbecfe050a..aa8aa5ec1d1 100644 --- a/doc/man3/EVP_PKEY_decapsulate.pod +++ b/doc/man3/EVP_PKEY_decapsulate.pod @@ -40,7 +40,7 @@ Instead, the shared secret must be used to derive a key that is used to authenticate data subsequently received from the peer. If I is NULL then the size of the output shared secret buffer is written to I<*unwrappedlen> and no decapsulation is performed, this makes it -possible to determine the required buffer size at runtime. Otherwise, the +possible to determine the required buffer size at run time. Otherwise, the decapsulated secret data is written to I and the length of shared secret is written to I<*unwrappedlen>. @@ -51,8 +51,8 @@ validate it is of sufficient size to hold the result of the operation. Absent detailed prior knowledge of the internals of the specific KEM algorithm, callers SHOULD NOT assume that the returned shared secret is necessarily of the maximum possible length. -The actual length returned via I<*unwrappedlen> SHOULD be used to determine the -actual length of the output. +The length returned via I<*unwrappedlen> SHOULD be used to determine the actual +length of the output. =head1 NOTES diff --git a/doc/man3/EVP_PKEY_encapsulate.pod b/doc/man3/EVP_PKEY_encapsulate.pod index 4925ec1d381..0a36c797716 100644 --- a/doc/man3/EVP_PKEY_encapsulate.pod +++ b/doc/man3/EVP_PKEY_encapsulate.pod @@ -58,7 +58,7 @@ is large enough to hold the result written to I. Absent detailed prior knowledge of the internals of the specific KEM algorithm, callers SHOULD NOT assume that the returned shared secret and ciphertext are necessarily of the maximum possible length. -The actual lengths returned via I<*wrappedkeylen> and I<*genkeylen> SHOULD +The lengths returned via I<*wrappedkeylen> and I<*genkeylen> SHOULD be used to determine the actual lengths of the outputs. =head1 NOTES diff --git a/doc/man3/EVP_PKEY_fromdata.pod b/doc/man3/EVP_PKEY_fromdata.pod index dab500b5902..76881ef14e4 100644 --- a/doc/man3/EVP_PKEY_fromdata.pod +++ b/doc/man3/EVP_PKEY_fromdata.pod @@ -34,8 +34,8 @@ EVP_PKEY_fromdata() creates the structure to store a key or key parameters, given data from I, I and a context that's been initialized with EVP_PKEY_fromdata_init(). The result is written to I<*ppkey>. I is described in L. -The parameters that can be used for various types of key are as described by the -diverse "Common parameters" sections of the +The parameters that can be used for various types of key are as described by +the various "Common parameters" sections of the L(7)|EVP_PKEY-RSA(7)/Common RSA parameters>, L(7)|EVP_PKEY-DSA(7)/Common DSA & DH parameters>, L(7)|EVP_PKEY-DH(7)/Common DH parameters>, @@ -43,7 +43,10 @@ L(7)|EVP_PKEY-EC(7)/Common EC parameters>, L(7)|EVP_PKEY-ED448(7)/Common X25519, X448, ED25519 and ED448 parameters>, L(7)|EVP_PKEY-X25519(7)/Common X25519, X448, ED25519 and ED448 parameters>, L(7)|EVP_PKEY-X448(7)/Common X25519, X448, ED25519 and ED448 parameters>, -and L(7)|EVP_PKEY-ED25519(7)/Common X25519, X448, ED25519 and ED448 parameters> pages. +L(7)|EVP_PKEY-ED25519(7)/Common X25519, X448, ED25519 and ED448 parameters>, +and +L +pages. =for comment the awful list of links above is made this way so we get nice rendering as a man-page while still getting proper links in HTML @@ -257,16 +260,28 @@ example with L. =head1 SEE ALSO -L, L, L, -L, L, -L, L, L, L, -L, L, L, -L, L +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L. =head1 HISTORY These functions were added in OpenSSL 3.0. +Support for B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/EVP_PKEY_keygen.pod b/doc/man3/EVP_PKEY_keygen.pod index d0e3f3736e4..3599f899454 100644 --- a/doc/man3/EVP_PKEY_keygen.pod +++ b/doc/man3/EVP_PKEY_keygen.pod @@ -100,11 +100,18 @@ If I is C, a B parameter must be given to specify the size of the RSA key. If I is C, a string parameter must be given to specify the name of the EC curve. -If I is C, C, C, C, or C -no further parameter is needed. Starting from OpenSSL version 3.5, other -key types may be possible if they are supplied by the loaded providers. -EVP_PKEY_Q_keygen() may be usable with such key types as long as -they do not require further parameters. +If I is: +C, +C, +C, +C, +C, +C, +C, or +C +no further parameters are needed. Other key types may be possible if they are +supplied by the loaded providers. EVP_PKEY_Q_keygen() may be usable with such +key types as long as they do not require further parameters. =head1 RETURN VALUES diff --git a/doc/man3/EVP_PKEY_new.pod b/doc/man3/EVP_PKEY_new.pod index 63df1396efb..c9bf80b767d 100644 --- a/doc/man3/EVP_PKEY_new.pod +++ b/doc/man3/EVP_PKEY_new.pod @@ -94,8 +94,16 @@ EVP_PKEY_new_raw_private_key_ex() allocates a new B. Unless an engine should be used for the key type, a provider for the key is found using the library context I and the property query string I. The I argument indicates what kind of key this is. The value should be a -string for a public key algorithm that supports raw private keys, i.e one of -"X25519", "ED25519", "X448" or "ED448". I points to the raw private key +string for a public key algorithm that supports raw private keys, e.g., one of: +C, +C, +C, +C, +C, +C, +or +C. +I points to the raw private key data for this B which should be of length I. The length should be appropriate for the type of the key. The public key data will be automatically derived from the given private key data (if appropriate for the @@ -119,13 +127,27 @@ EVP_PKEY_new_raw_public_key_ex() works in the same way as EVP_PKEY_new_raw_private_key_ex() except that I points to the raw public key data. The B structure will be initialised without any private key information. Algorithm types that support raw public keys are -"X25519", "ED25519", "X448" or "ED448". +B, +B, +B, +B, +B, +B, +and +B. EVP_PKEY_new_raw_public_key() works in the same way as EVP_PKEY_new_raw_private_key() except that I points to the raw public key data. The B structure will be initialised without any private key information. Algorithm types that support raw public keys are -B, B, B or B. +B. +B, +B, +B +B, +B, +and +B. EVP_PKEY_new_mac_key() works in the same way as EVP_PKEY_new_raw_private_key(). New applications should use EVP_PKEY_new_raw_private_key() instead. @@ -137,8 +159,19 @@ actually written. If the buffer I is NULL then I<*len> is populated with the number of bytes required to hold the key. The calling application is responsible for ensuring that the buffer is large enough to receive the private key data. This function only works for algorithms that support raw private keys. -Currently this is: B, B, B, -B, B, B or B. +These include: +B, +B, +B, +B, +B, +B, +and +B. +EVP_PKEY_get_raw_private_key() also works with B, B and +B keys, which don't have legacy numeric I assigments, but +their raw form is nevertheless available. + EVP_PKEY_get_raw_public_key() fills the buffer provided by I with raw public key data. The size of the I buffer should be in I<*len> on entry @@ -147,8 +180,15 @@ actually written. If the buffer I is NULL then I<*len> is populated with the number of bytes required to hold the key. The calling application is responsible for ensuring that the buffer is large enough to receive the public key data. This function only works for algorithms that support raw public keys. -Currently this is: B, B, B or -B. +These include: +B, +B, +B, +and +B +EVP_PKEY_get_raw_public_key() also works with B, B and +B keys, which don't have legacy numeric I assigments, but +their raw form is nevertheless available. EVP_PKEY_new_CMAC_key() works in the same way as EVP_PKEY_new_raw_private_key() except it is only for the B algorithm type. In addition to the @@ -183,8 +223,20 @@ EVP_PKEY_get_raw_public_key() return 1 for success and 0 for failure. =head1 SEE ALSO -L, L, L or -L +L, +L, +L, +L, +L, +L. +L, +L, +L, +L, +L, +L, +L, +L. =head1 HISTORY @@ -208,6 +260,8 @@ The documentation of B was amended in OpenSSL 3.0 to allow there to be the private part of the keypair without the public part, where this was previously implied to be disallowed. +Support for B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2002-2022 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/EVP_PKEY_set1_encoded_public_key.pod b/doc/man3/EVP_PKEY_set1_encoded_public_key.pod index 2b9f27aaa00..2393ca0e027 100644 --- a/doc/man3/EVP_PKEY_set1_encoded_public_key.pod +++ b/doc/man3/EVP_PKEY_set1_encoded_public_key.pod @@ -27,18 +27,24 @@ see L: =head1 DESCRIPTION EVP_PKEY_set1_encoded_public_key() can be used to set the public key value -within an existing EVP_PKEY object. For the built-in OpenSSL algorithms this -currently only works for those that support key exchange. Parameters are not -set as part of this operation, so typically an application will create an -EVP_PKEY first, set the parameters on it, and then call this function. +within an existing EVP_PKEY object, which does not yet have either a public or +private key assigned. +For the built-in OpenSSL algorithms this currently only works for those that +support key exchange or key encapsulation. +Parameters are not set as part of this operation, so typically an application +will create an EVP_PKEY first, set the parameters on it, and then call this +function. For example setting the parameters might be done using L. The format for the encoded public key will depend on the algorithm in use. For DH it should be encoded as a positive integer in big-endian form. For EC is should be a point conforming to Sec. 2.3.4 of the SECG SEC 1 ("Elliptic -Curve Cryptography") standard. For X25519 and X448 it should be encoded in a -format as defined by RFC7748. +Curve Cryptography") standard. For B and B it should be encoded +in the format defined by RFC7748. +For B, B and B, this is the public key +format defined in B (the 12-bit per-coefficient encoded public I +vector and 32-byte matrix seed I). The key to be updated is supplied in B. The buffer containing the encoded key is pointed to be B. The length of the buffer is supplied in B. @@ -117,9 +123,17 @@ performing a key exchange operation. =head1 SEE ALSO -L, L, -L, L, -L, L, L, L +L, +L, +L, +L, +L, +L, +L, +L, +L, +L, +L. =head1 HISTORY @@ -129,6 +143,8 @@ added in OpenSSL 3.0. EVP_PKEY_set1_tls_encodedpoint() and EVP_PKEY_get1_tls_encodedpoint() were deprecated in OpenSSL 3.0. +Support for B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2020 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/EVP_PKEY_todata.pod b/doc/man3/EVP_PKEY_todata.pod index 88545454378..a03c2933f6d 100644 --- a/doc/man3/EVP_PKEY_todata.pod +++ b/doc/man3/EVP_PKEY_todata.pod @@ -41,16 +41,26 @@ EVP_PKEY_todata() and EVP_PKEY_export() return 1 for success and 0 for failure. =head1 SEE ALSO -L, L, +L, +L, L, -L, L, L, L, -L, L, L, -L, L +L, +L, +L, +L +L, +L, +L, +L, +L, +L. =head1 HISTORY These functions were added in OpenSSL 3.0. +Support for B and B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2021-2022 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod index 064ef55e0f5..d232c37a996 100644 --- a/doc/man3/SSL_CONF_cmd.pod +++ b/doc/man3/SSL_CONF_cmd.pod @@ -169,10 +169,25 @@ Since TLS 1.2 has neither keyshares nor a hello retry mechanism, with TLS 1.2 the enriched syntax is ultimately equivalent to just a simple ordered list of groups, as with the simple form above. -Groups for B in the default provider are B, B, -B, B, B, B, B, B, -B, B, B, -B and B. +The supported groups for B include: +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B +B, +B, +and +B. + Additional providers may make available further algorithms via the TLS-GROUP capability. See L. @@ -441,9 +456,24 @@ applicable (e.g. B, B) or an OpenSSL OID name (e.g. B). Group names are case sensitive. The list should be in order of preference with the most preferred group first. -Currently supported groups for B are B, B, B, -B, B, B, B, B, B, -B. +The supported groups for B include: +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B +B, +B, +and +B. =item B @@ -823,6 +853,8 @@ added in OpenSSL 3.2. B was added in OpenSSL 3.3. +Support for B was added in OpenSSL 3.5. + =head1 COPYRIGHT Copyright 2012-2024 The OpenSSL Project Authors. All Rights Reserved. diff --git a/doc/man3/SSL_CTX_set1_curves.pod b/doc/man3/SSL_CTX_set1_curves.pod index db19721d8d8..dd0930e8d43 100755 --- a/doc/man3/SSL_CTX_set1_curves.pod +++ b/doc/man3/SSL_CTX_set1_curves.pod @@ -44,12 +44,22 @@ functions (i.e. SSL_CTX_set1_groups_list() and SSL_set1_groups_list()). SSL_CTX_set1_groups() sets the supported groups for B to B groups in the array B. The array consist of all NIDs of supported groups. -Currently supported groups for B are B, -B, B, B, B, -B, B, -B, B, B, -B, B and B. -OpenSSL will use this array in different ways depending on TLS role and version: +The supported groups for B include: +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, +B, and +B. +OpenSSL will use this array in different ways based on the TLS version, and +whether the groups are used in a client or server. For a TLS client, the groups are used directly in the supported groups extension. The extension's preference order, to be evaluated by the server, is @@ -73,11 +83,27 @@ to use SSL_CTX_set1_groups_list() with the ability to specify group tuples. SSL_CTX_set1_groups_list() sets the supported groups for B to string I. In contrast to SSL_CTX_set1_groups(), the names of the -groups, rather than their NIDs, are used. Currently supported groups for -B are B, B, B, B, B, -B, B, B, -B, B, B, B and B. Support -for other groups may be added by external providers. +groups, rather than their NIDs, are used. + +The supported groups for B include: +B, +B, +B, +B, +B, +B, +B, +B, +B +B, +B, +B, +B, +B, +B, and +B. +Support for other groups may be added by external providers. + Each group can be either the B name (e.g. B), some other commonly used name where applicable (e.g. B, B) or an OpenSSL OID name (e.g. B). Group names are case sensitive. The preferred group names @@ -247,6 +273,8 @@ was added in OpenSSL 3.0.0. Support for ignoring unknown groups in SSL_CTX_set1_groups_list() and SSL_set1_groups_list() was added in OpenSSL 3.3. +Support for B was added in OpenSSL 3.5. + Earlier versions of this document described the list as a preference order. However, OpenSSL's behavior as a TLS 1.3 server is to consider I supported groups as comparable in security. diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod index c5c1237b8e5..a7d3efb0d19 100644 --- a/doc/man7/OSSL_PROVIDER-FIPS.pod +++ b/doc/man7/OSSL_PROVIDER-FIPS.pod @@ -140,6 +140,9 @@ This is an unapproved algorithm. =item X448, see L +=for comment TODO(ML-KEM) L once ML-KEM is supported in the + FIPS module. + =item TLS1-PRF =item HKDF diff --git a/doc/man7/OSSL_PROVIDER-base.pod b/doc/man7/OSSL_PROVIDER-base.pod index 696c4990c3e..f7284e91c4d 100644 --- a/doc/man7/OSSL_PROVIDER-base.pod +++ b/doc/man7/OSSL_PROVIDER-base.pod @@ -102,6 +102,8 @@ are also available in the default provider. =item ML-DSA-87 +=for comment TODO(ML-KEM): We don't yet have encoders for ML-KEM. + =back In addition to this provider, all of these encoding algorithms are also @@ -142,6 +144,8 @@ combination with the FIPS provider. =item ML-DSA-87 +=for comment We don't yet have decoders for MLKEM... + =back In addition to this provider, all of these decoding algorithms are also diff --git a/doc/man7/OSSL_PROVIDER-default.pod b/doc/man7/OSSL_PROVIDER-default.pod index f5c30c9839e..7489ecd26b1 100644 --- a/doc/man7/OSSL_PROVIDER-default.pod +++ b/doc/man7/OSSL_PROVIDER-default.pod @@ -247,10 +247,6 @@ The OpenSSL default provider supports these operations and algorithms: =over 4 -=item DH, see L - -=item DHX, see L - =item DSA, see L =item RSA, see L @@ -259,15 +255,31 @@ The OpenSSL default provider supports these operations and algorithms: =item EC, see L +=item ED25519, see L + +=item ED448, see L + +=item SM2, see L + +=item DH, see L + +=item DHX, see L + =item X25519, see L =item X448, see L -=item ED25519, see L +=item ML-DSA-44, see L -=item ED448, see L +=item ML-DSA-65, see L + +=item ML-DSA-87, see L + +=item MK-KEM-512, see L -=for comment We don't yet have the corresponding MLKEM doc in the works. +=item MK-KEM-768, see L + +=item MK-KEM-1024, see L =item TLS1-PRF @@ -283,20 +295,6 @@ The OpenSSL default provider supports these operations and algorithms: =item CMAC, see L -=item SM2, see L - -=item ML-DSA-44, see L - -=item ML-DSA-65, see L - -=item ML-DSA-87, see L - -=item ML-KEM-512, see L - -=item ML-KEM-768, see L - -=item ML-KEM-1024, see L - =back =head2 Random Number Generation diff --git a/doc/man7/fips_module.pod b/doc/man7/fips_module.pod index 6e0af8edab3..7d7ae647e03 100644 --- a/doc/man7/fips_module.pod +++ b/doc/man7/fips_module.pod @@ -515,7 +515,7 @@ See L "pkcs1" padding is no longer approved. -See L and +See L and L =item RSA Signatures @@ -568,6 +568,8 @@ internally for non security purposes. The unapproved (non FIPS validated) algorithms have a property query value of "fips=no". +=for comment TODO(ML-KEM) Once in the FIPS module. + The following algorithms use a unique indicator and do not trigger the indicator callback. diff --git a/doc/man7/ossl-guide-migration.pod b/doc/man7/ossl-guide-migration.pod index fd0654c6235..7e365ed18f6 100644 --- a/doc/man7/ossl-guide-migration.pod +++ b/doc/man7/ossl-guide-migration.pod @@ -421,7 +421,7 @@ EC EVP_PKEYs with the SM2 curve have been reworked to automatically become EVP_PKEY_SM2 rather than EVP_PKEY_EC. Unlike in previous OpenSSL versions, this means that applications cannot -call C to get SM2 computations. +call B to get SM2 computations. Parameter and key generation is also reworked to make it possible to generate EVP_PKEY_SM2 parameters and keys. Applications must now generate @@ -1058,14 +1058,23 @@ APIs, or alternatively use L or L. =head4 Deprecated low-level key parameter getters Functions that access low-level objects directly such as L are now -deprecated. Applications should use one of L, -L, l, -L, L or -L to access fields from an EVP_PKEY. -Gettable parameters are listed in L, -L, L, -L, L and -L. +deprecated. Applications should use one of: +L, +L, +L, +L, +L, or +L, +to access fields from an EVP_PKEY. +Gettable parameters are listed in: +L, +L, +L, +L, +L, +L, +and +L. Applications may also use L to return all fields. =head4 Deprecated low-level key parameter setters