2019-05-27 08:55:01 +02:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
2016-06-22 17:49:14 +01:00
/*
* Diffie - Hellman secret to be used with kpp API along with helper functions
*
* Copyright ( c ) 2016 , Intel Corporation
* Authors : Salvatore Benedetto < salvatore . benedetto @ intel . com >
*/
# ifndef _CRYPTO_DH_
# define _CRYPTO_DH_
2016-10-21 04:58:20 +02:00
/**
* DOC : DH Helper Functions
*
* To use DH with the KPP cipher API , the following data structure and
* functions should be used .
*
* To use DH with KPP , the following functions should be used to operate on
* a DH private key . The packet private key that can be set with
* the KPP API function call of crypto_kpp_set_secret .
*/
/**
* struct dh - define a DH private key
*
* @ key : Private DH key
* @ p : Diffie - Hellman parameter P
* @ g : Diffie - Hellman generator G
* @ key_size : Size of the private DH key
* @ p_size : Size of DH parameter P
* @ g_size : Size of DH generator G
*/
2016-06-22 17:49:14 +01:00
struct dh {
2022-02-21 13:10:50 +01:00
const void * key ;
const void * p ;
const void * g ;
2016-06-22 17:49:14 +01:00
unsigned int key_size ;
unsigned int p_size ;
unsigned int g_size ;
} ;
2016-10-21 04:58:20 +02:00
/**
* crypto_dh_key_len ( ) - Obtain the size of the private DH key
* @ params : private DH key
*
* This function returns the packet DH key size . A caller can use that
* with the provided DH private key reference to obtain the required
* memory size to hold a packet key .
*
* Return : size of the key in bytes
*/
2017-09-29 12:21:05 +03:00
unsigned int crypto_dh_key_len ( const struct dh * params ) ;
2016-10-21 04:58:20 +02:00
/**
* crypto_dh_encode_key ( ) - encode the private key
* @ buf : Buffer allocated by the caller to hold the packet DH
* private key . The buffer should be at least crypto_dh_key_len
* bytes in size .
* @ len : Length of the packet private key buffer
* @ params : Buffer with the caller - specified private key
*
* The DH implementations operate on a packet representation of the private
* key .
*
* Return : - EINVAL if buffer has insufficient size , 0 on success
*/
2016-06-22 17:49:14 +01:00
int crypto_dh_encode_key ( char * buf , unsigned int len , const struct dh * params ) ;
2016-10-21 04:58:20 +02:00
/**
* crypto_dh_decode_key ( ) - decode a private key
* @ buf : Buffer holding a packet key that should be decoded
2017-05-25 10:18:03 +03:00
* @ len : Length of the packet private key buffer
2016-10-21 04:58:20 +02:00
* @ params : Buffer allocated by the caller that is filled with the
2017-05-25 10:18:03 +03:00
* unpacked DH private key .
2016-10-21 04:58:20 +02:00
*
* The unpacking obtains the private key by pointing @ p to the correct location
* in @ buf . Thus , both pointers refer to the same memory .
*
* Return : - EINVAL if buffer has insufficient size , 0 on success
*/
2016-06-22 17:49:14 +01:00
int crypto_dh_decode_key ( const char * buf , unsigned int len , struct dh * params ) ;
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 13:10:51 +01:00
/**
* __crypto_dh_decode_key ( ) - decode a private key without parameter checks
* @ buf : Buffer holding a packet key that should be decoded
* @ len : Length of the packet private key buffer
* @ params : Buffer allocated by the caller that is filled with the
* unpacked DH private key .
*
* Internal function providing the same services as the exported
* crypto_dh_decode_key ( ) , but without any of those basic parameter
* checks conducted by the latter .
*
* Return : - EINVAL if buffer has insufficient size , 0 on success
*/
int __crypto_dh_decode_key ( const char * buf , unsigned int len ,
struct dh * params ) ;
2016-06-22 17:49:14 +01:00
# endif