2019-05-27 06:55:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2016-06-22 16:49:14 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016, Intel Corporation
|
|
|
|
* Authors: Salvatore Benedetto <salvatore.benedetto@intel.com>
|
|
|
|
*/
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <crypto/dh.h>
|
|
|
|
#include <crypto/kpp.h>
|
|
|
|
|
2022-02-21 12:10:49 +00:00
|
|
|
#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 * sizeof(int))
|
2016-06-22 16:49:14 +00:00
|
|
|
|
2018-07-27 22:36:11 +00:00
|
|
|
static inline u8 *dh_pack_data(u8 *dst, u8 *end, const void *src, size_t size)
|
2016-06-22 16:49:14 +00:00
|
|
|
{
|
2018-07-27 22:36:11 +00:00
|
|
|
if (!dst || size > end - dst)
|
|
|
|
return NULL;
|
2016-06-22 16:49:14 +00:00
|
|
|
memcpy(dst, src, size);
|
|
|
|
return dst + size;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline const u8 *dh_unpack_data(void *dst, const void *src, size_t size)
|
|
|
|
{
|
|
|
|
memcpy(dst, src, size);
|
|
|
|
return src + size;
|
|
|
|
}
|
|
|
|
|
2017-09-29 09:21:04 +00:00
|
|
|
static inline unsigned int dh_data_size(const struct dh *p)
|
2016-06-22 16:49:14 +00:00
|
|
|
{
|
2022-02-21 12:10:49 +00:00
|
|
|
return p->key_size + p->p_size + p->g_size;
|
2016-06-22 16:49:14 +00:00
|
|
|
}
|
|
|
|
|
2017-09-29 09:21:05 +00:00
|
|
|
unsigned int crypto_dh_key_len(const struct dh *p)
|
2016-06-22 16:49:14 +00:00
|
|
|
{
|
|
|
|
return DH_KPP_SECRET_MIN_SIZE + dh_data_size(p);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_dh_key_len);
|
|
|
|
|
|
|
|
int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params)
|
|
|
|
{
|
|
|
|
u8 *ptr = buf;
|
2018-07-27 22:36:11 +00:00
|
|
|
u8 * const end = ptr + len;
|
2016-06-22 16:49:14 +00:00
|
|
|
struct kpp_secret secret = {
|
|
|
|
.type = CRYPTO_KPP_SECRET_TYPE_DH,
|
|
|
|
.len = len
|
|
|
|
};
|
|
|
|
|
2018-07-27 22:36:11 +00:00
|
|
|
if (unlikely(!len))
|
2016-06-22 16:49:14 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2018-07-27 22:36:11 +00:00
|
|
|
ptr = dh_pack_data(ptr, end, &secret, sizeof(secret));
|
|
|
|
ptr = dh_pack_data(ptr, end, ¶ms->key_size,
|
|
|
|
sizeof(params->key_size));
|
|
|
|
ptr = dh_pack_data(ptr, end, ¶ms->p_size, sizeof(params->p_size));
|
|
|
|
ptr = dh_pack_data(ptr, end, ¶ms->g_size, sizeof(params->g_size));
|
|
|
|
ptr = dh_pack_data(ptr, end, params->key, params->key_size);
|
|
|
|
ptr = dh_pack_data(ptr, end, params->p, params->p_size);
|
|
|
|
ptr = dh_pack_data(ptr, end, params->g, params->g_size);
|
|
|
|
if (ptr != end)
|
2016-06-22 16:49:14 +00:00
|
|
|
return -EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_dh_encode_key);
|
|
|
|
|
crypto: dh - split out deserialization code from crypto_dh_decode()
A subsequent commit will introduce "dh" wrapping templates of the form
"ffdhe2048(dh)", "ffdhe3072(dh)" and so on in order to provide built-in
support for the well-known safe-prime ffdhe group parameters specified in
RFC 7919.
Those templates' ->set_secret() will wrap the inner "dh" implementation's
->set_secret() and set the ->p and ->g group parameters as appropriate on
the way inwards. More specifically,
- A ffdheXYZ(dh) user would call crypto_dh_encode() on a struct dh instance
having ->p == ->g == NULL as well as ->p_size == ->g_size == 0 and pass
the resulting buffer to the outer ->set_secret().
- This outer ->set_secret() would then decode the struct dh via
crypto_dh_decode_key(), set ->p, ->g, ->p_size as well as ->g_size as
appropriate for the group in question and encode the struct dh again
before passing it further down to the inner "dh"'s ->set_secret().
The problem is that crypto_dh_decode_key() implements some basic checks
which would reject parameter sets with ->p_size == 0 and thus, the ffdheXYZ
templates' ->set_secret() cannot use it as-is for decoding the passed
buffer. As the inner "dh"'s ->set_secret() will eventually conduct said
checks on the final parameter set anyway, the outer ->set_secret() really
only needs the decoding functionality.
Split out the pure struct dh decoding part from crypto_dh_decode_key() into
the new __crypto_dh_decode_key().
__crypto_dh_decode_key() gets defined in crypto/dh_helper.c, but will have
to get called from crypto/dh.c and thus, its declaration must be somehow
made available to the latter. Strictly speaking, __crypto_dh_decode_key()
is internal to the dh_generic module, yet it would be a bit over the top
to introduce a new header like e.g. include/crypto/internal/dh.h
containing just a single prototype. Add the __crypto_dh_decode_key()
declaration to include/crypto/dh.h instead.
Provide a proper kernel-doc annotation, even though
__crypto_dh_decode_key() is purposedly not on the function list specified
in Documentation/crypto/api-kpp.rst.
Signed-off-by: Nicolai Stange <nstange@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-02-21 12:10:51 +00:00
|
|
|
int __crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
|
2016-06-22 16:49:14 +00:00
|
|
|
{
|
|
|
|
const u8 *ptr = buf;
|
|
|
|
struct kpp_secret secret;
|
|
|
|
|
|
|
|
if (unlikely(!buf || len < DH_KPP_SECRET_MIN_SIZE))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ptr = dh_unpack_data(&secret, ptr, sizeof(secret));
|
|
|
|
if (secret.type != CRYPTO_KPP_SECRET_TYPE_DH)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ptr = dh_unpack_data(¶ms->key_size, ptr, sizeof(params->key_size));
|
|
|
|
ptr = dh_unpack_data(¶ms->p_size, ptr, sizeof(params->p_size));
|
|
|
|
ptr = dh_unpack_data(¶ms->g_size, ptr, sizeof(params->g_size));
|
|
|
|
if (secret.len != crypto_dh_key_len(params))
|
|
|
|
return -EINVAL;
|
|
|
|
|
crypto: dh - split out deserialization code from crypto_dh_decode()
A subsequent commit will introduce "dh" wrapping templates of the form
"ffdhe2048(dh)", "ffdhe3072(dh)" and so on in order to provide built-in
support for the well-known safe-prime ffdhe group parameters specified in
RFC 7919.
Those templates' ->set_secret() will wrap the inner "dh" implementation's
->set_secret() and set the ->p and ->g group parameters as appropriate on
the way inwards. More specifically,
- A ffdheXYZ(dh) user would call crypto_dh_encode() on a struct dh instance
having ->p == ->g == NULL as well as ->p_size == ->g_size == 0 and pass
the resulting buffer to the outer ->set_secret().
- This outer ->set_secret() would then decode the struct dh via
crypto_dh_decode_key(), set ->p, ->g, ->p_size as well as ->g_size as
appropriate for the group in question and encode the struct dh again
before passing it further down to the inner "dh"'s ->set_secret().
The problem is that crypto_dh_decode_key() implements some basic checks
which would reject parameter sets with ->p_size == 0 and thus, the ffdheXYZ
templates' ->set_secret() cannot use it as-is for decoding the passed
buffer. As the inner "dh"'s ->set_secret() will eventually conduct said
checks on the final parameter set anyway, the outer ->set_secret() really
only needs the decoding functionality.
Split out the pure struct dh decoding part from crypto_dh_decode_key() into
the new __crypto_dh_decode_key().
__crypto_dh_decode_key() gets defined in crypto/dh_helper.c, but will have
to get called from crypto/dh.c and thus, its declaration must be somehow
made available to the latter. Strictly speaking, __crypto_dh_decode_key()
is internal to the dh_generic module, yet it would be a bit over the top
to introduce a new header like e.g. include/crypto/internal/dh.h
containing just a single prototype. Add the __crypto_dh_decode_key()
declaration to include/crypto/dh.h instead.
Provide a proper kernel-doc annotation, even though
__crypto_dh_decode_key() is purposedly not on the function list specified
in Documentation/crypto/api-kpp.rst.
Signed-off-by: Nicolai Stange <nstange@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-02-21 12:10:51 +00:00
|
|
|
/* Don't allocate memory. Set pointers to data within
|
|
|
|
* the given buffer
|
|
|
|
*/
|
|
|
|
params->key = (void *)ptr;
|
|
|
|
params->p = (void *)(ptr + params->key_size);
|
|
|
|
params->g = (void *)(ptr + params->key_size + params->p_size);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = __crypto_dh_decode_key(buf, len, params);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2017-11-06 02:30:46 +00:00
|
|
|
/*
|
|
|
|
* Don't permit the buffer for 'key' or 'g' to be larger than 'p', since
|
|
|
|
* some drivers assume otherwise.
|
|
|
|
*/
|
|
|
|
if (params->key_size > params->p_size ||
|
2022-02-21 12:10:49 +00:00
|
|
|
params->g_size > params->p_size)
|
2017-11-06 02:30:46 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2017-11-06 02:30:45 +00:00
|
|
|
/*
|
|
|
|
* Don't permit 'p' to be 0. It's not a prime number, and it's subject
|
|
|
|
* to corner cases such as 'mod 0' being undefined or
|
|
|
|
* crypto_kpp_maxsize() returning 0.
|
|
|
|
*/
|
|
|
|
if (memchr_inv(params->p, 0, params->p_size) == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-06-22 16:49:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
|