kernel/linux.git/crypto/dh.c, branch v6.6.132

crypto: api - Use data directly in completion function

2023-02-13T10:35:14+00:00

This patch does the final flag day conversion of all completion functions which are now all contained in the Crypto API. Signed-off-by: Herbert Xu

crypto: dh - Use helper to set reqsize

2022-12-02T10:12:40+00:00

The value of reqsize must only be changed through the helper. Signed-off-by: Herbert Xu

crypto: add init/exit annotations to init/exit funcs

2022-09-24T08:14:43+00:00

Add missing __init/__exit annotations to init/exit funcs. Signed-off-by: Xiu Jianfeng Signed-off-by: Herbert Xu

crypto: dh - Remove the unused function dh_safe_prime_dh_alg()

2022-03-14T02:45:45+00:00

Fix the following W=1 kernel warnings: crypto/dh.c:311:31: warning: unused function 'dh_safe_prime_dh_alg' [-Wunused-function] Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: Herbert Xu

crypto: dh - calculate Q from P for the full public key verification

2022-03-02T22:47:52+00:00

As the ->q in struct dh_ctx gets never set anywhere, the code in dh_is_pubkey_valid() for doing the full public key validation in accordance to SP800-56Arev3 is effectively dead. However, for safe-prime groups Q = (P - 1)/2 by definition and as the safe-prime groups are the only possible groups in FIPS mode (via those ffdheXYZ() templates), this enables dh_is_pubkey_valid() to calculate Q on the fly for these. Implement this. With this change, the last code accessing struct dh_ctx's ->q is now gone. Remove this member from struct dh_ctx. Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - allow for passing NULL to the ffdheXYZ(dh)s' ->set_secret()

2022-03-02T22:47:51+00:00

Ephemeral key generation can be requested from any of the ffdheXYZ(dh) variants' common ->set_secret() by passing it an (encoded) struct dh with the key parameter being unset, i.e. with ->key_size == 0. As the whole purpose of the ffdheXYZ(dh) templates is to fill in the group parameters as appropriate, they expect ->p and ->g to be unset in any input struct dh as well. This means that a user would have to encode an all-zeroes struct dh instance via crypto_dh_encode_key() when requesting ephemeral key generation from a ffdheXYZ(dh) instance, which is kind of pointless. Make dh_safe_prime_set_secret() to decode a struct dh from the supplied buffer only if the latter is non-NULL and initialize it with all zeroes otherwise. That is, it is now possible to call crypto_kpp_set_secret(tfm, NULL, 0); on any ffdheXYZ(dh) tfm for requesting ephemeral key generation. Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - implement private key generation primitive for ffdheXYZ(dh)

2022-03-02T22:47:51+00:00

The support for NVME in-band authentication currently in the works ([1]) needs to generate ephemeral DH keys for use with the RFC 7919 safe-prime FFDHE groups. In analogy to ECDH and its ecc_gen_privkey(), implement a dh_safe_prime_gen_privkey() and invoke it from the ffdheXYZ(dh) templates' common ->set_secret(), i.e. dh_safe_prime_set_secret(), in case the input ->key_size is zero. As the RFC 7919 FFDHE groups are classified as approved safe-prime groups by SP800-56Arev3, it's worthwhile to make the new dh_safe_prime_gen_privkey() to follow the approach specified in SP800-56Arev3, sec. 5.6.1.1.3 ("Key-Pair Generation Using Extra Random Bits") in order to achieve conformance. SP800-56Arev3 specifies a lower as well as an upper bound on the generated key's length: - it must be >= two times the maximum supported security strength of the group in question and - it must be <= the length of the domain parameter Q. For any safe-prime group Q = (P - 1)/2 by definition and the individual maximum supported security strengths as specified by SP800-56Arev3 have been made available as part of the FFDHE dh_safe_prime definitions introduced with a previous patch. Make dh_safe_prime_gen_privkey() pick twice the maximum supported strength rounded up to the next power of two for the output key size. This choice respects both, the lower and upper bounds given by SP800-90Arev3 for any of the approved safe-prime groups and is also in line with the NVME base spec 2.0, which requires the key size to be >= 256bits. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - implement ffdheXYZ(dh) templates

2022-03-02T22:47:51+00:00

Current work on NVME in-band authentication support ([1]) needs to invoke DH with the FFDHE safe-prime group parameters specified in RFC 7919. Introduce a new CRYPTO_DH_RFC7919_GROUPS Kconfig option. If enabled, make dh_generic register a couple of ffdheXYZ(dh) templates, one for each group: ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh). Their respective ->set_secret() expects a (serialized) struct dh, just like the underlying "dh" implementation does, but with the P and G values unset so that the safe-prime constants for the given group can be filled in by the wrapping template. Internally, a struct dh_safe_prime instance is being defined for each of the ffdheXYZ(dh) templates as appropriate. In order to prepare for future key generation, fill in the maximum security strength values as specified by SP800-56Arev3 on the go, even though they're not needed at this point yet. Implement the respective ffdheXYZ(dh) crypto_template's ->create() by simply forwarding any calls to the __dh_safe_prime_create() helper introduced with the previous commit, passing the associated dh_safe_prime in addition to the received ->create() arguments. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - introduce common code for built-in safe-prime group support

2022-03-02T22:47:50+00:00

Recent work on NVME in-band authentication support ([1]) needs to invoke the "dh" KPP with the FFDHE safe-prime group parameters as specified in RFC 7919 and generate ephemeral keys suitable for the respective group. By coincidence, the requirements from NIST SP800-56Arev3, sec. 5.5.2 ("Assurance of Domain-Parameter Validity") basically boil down to disallowing any group parameters not among the approved safe-prime groups specified in either RFC 7919 or RFC 3526 in FIPS mode. Furthermore, SP800-56Arev3 specifies the respective security strength for each of the approved safe-prime groups, which has a direct impact on the minimum key lengths. In this light, it's desirable to introduce built-in support for the RFC 7919 safe-prime groups to the kernel's DH implementation, provide a SP800-56Arev3 conforming key generation primitive for those and render non-approved group parameters unusable in FIPS mode on the way. As suggested ([2]) in the course of discussion to previous iterations of this patchset, the built-in support for ffdhe groups would be best made available in the form of templates wrapping the existing "dh" implementation, one for each group specified by RFC 7919: ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh). As these templates differ only in the safe-prime constants they'd configure the inner "dh" transforms with, they can share almost all of their "dh"-wrapping template implementation code. Introduce this common code to dh_generic. The actual dump of the RFC 7919 safe-prime constants will be deferred to the next patch in order to facilitate review. The ephemeral key generation primitive mentioned above likewise deserves a patch on its own, as does the mechanism by which unapproved groups are rendered unusable in FIPS mode. Define a struct dh_safe_prime container for specifying the individual templates' associated safe-prime group constants. All ffdheXYZ(dh) template instances will store a pointer to such a dh_safe_prime in their context areas each. Implement the common __dh_safe_prime_create() template instantiation helper. The intention is that the individual ffdheXYZ(dh) crypto_templates' ->create() implementations will simply forward any calls to __dh_safe_prime_create(), passing a suitable dh_safe_prime in addition to the received ->create() arguments. __dh_safe_prime_create() would then create and register a kpp_instance as appropriate, storing the given dh_safe_prime pointer alongside a crypto_kpp_spawn for the inner "dh" kpp_alg in the context area. As the ffdheXYZ(dh) kpp_instances are supposed to act as proxies to the inner "dh" kpp_alg, make each of their associated crypto_kpp transforms to in turn own an inner "dh" transform, a pointer to which gets stored in the context area. Setup and teardown are getting handled from the outer ->init_tfm() and ->exit_tfm() respectively. In order to achieve the overall goal and let the ffdheXYZ(dh) kpp_instances configure the inner "dh" transforms with the respective group parameters, make their common ->set_secret(), the new dh_safe_prime_set_secret(), fill in the P and G values before forwarding the call to the inner "dh"'s ->set_secret(). Note that the outer ->set_secret() can obtain the P value associated with the given ffdheXYZ(dh) kpp_instance by means of the dh_safe_prime referenced from the latter's context. The value of G OTOH always equals constant 2 for the safe-prime groups. Finally, make the remaining two kpp_alg primitives both operating on kpp_requests, i.e. ->generate_public_key() and ->compute_shared_secret(), to merely forward any request to the inner "dh" implementation. However, a kpp_request instance received from the outside cannot get simply passed on as-is, because its associated transform (crypto_kpp_reqtfm()) will have been set to the outer ffdheXYZ(dh) one. In order to handle this, reserve some space in the outer ffdheXYZ(dh) kpp_requests' context areas for in turn storing an inner kpp_request suitable for "dh" each. Make the outer ->generate_public_key() and ->compute_shared_secret() respectively to setup this inner kpp_request by means of the new dh_safe_prime_prepare_dh_req() helper before handing it over to the "dh" implementation for further processing. dh_safe_prime_prepare_dh_req() basically copies the outer kpp_request received from the outside over to the inner one, but installs the inner transform and its own ->complete() proxy callback therein. This completion callback, the new dh_safe_prime_complete_req(), doesn't do anything beyond completing the outer request. Note that there exist some examples in crypto/, which would simply install the completion handler from the outer request at the inner one in similar setups, e.g. seqiv. However, this would mean that the user-provided completion handler won't get called with the address of the outer kpp_request initially submitted and the handler might not be prepared for this. Users could certainly work around this by setting the callback ->data properly, but IMO it's cleaner this way. Furthermore, it might make sense to extend dh_safe_prime_complete_req() in the future and move e.g. those post-computation FIPS checks from the generic "dh" implementation to the ffdheXYZ(dh) templates. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de [2] https://lore.kernel.org/r/20211217055227.GA20698@gondor.apana.org.au Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - remove struct dh's ->q member

2022-03-02T22:47:50+00:00

The only current user of the DH KPP algorithm, the keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q in struct dh. Remove it and any associated (de)serialization code in crypto_dh_encode_key() and crypto_dh_decode_key. Adjust the encoded ->secret values in testmgr's DH test vectors accordingly. Note that the dh-generic implementation would have initialized its struct dh_ctx's ->q from the decoded struct dh's ->q, if present. If this struct dh_ctx's ->q would ever have been non-NULL, it would have enabled a full key validation as specified in NIST SP800-56A in dh_is_pubkey_valid(). However, as outlined above, ->q is always NULL in practice and the full key validation code is effectively dead. A later patch will make dh_is_pubkey_valid() to calculate Q from P on the fly, if possible, so don't remove struct dh_ctx's ->q now, but leave it there until that has happened. Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

kernel/linux.git/crypto/dh.c, branch v6.6.132

crypto: api - Use data directly in completion function

crypto: dh - Use helper to set reqsize

crypto: add __init/__exit annotations to init/exit funcs

crypto: dh - Remove the unused function dh_safe_prime_dh_alg()

crypto: dh - calculate Q from P for the full public key verification

crypto: dh - allow for passing NULL to the ffdheXYZ(dh)s' ->set_secret()

crypto: dh - implement private key generation primitive for ffdheXYZ(dh)

crypto: dh - implement ffdheXYZ(dh) templates

crypto: dh - introduce common code for built-in safe-prime group support

crypto: dh - remove struct dh's ->q member

crypto: add init/exit annotations to init/exit funcs