2019-05-27 09:55:01 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2016-06-22 19:49:14 +03: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 15:10:49 +03:00
# define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 * sizeof(int))
2016-06-22 19:49:14 +03:00
2018-07-28 01:36:11 +03:00
static inline u8 * dh_pack_data ( u8 * dst , u8 * end , const void * src , size_t size )
2016-06-22 19:49:14 +03:00
{
2018-07-28 01:36:11 +03:00
if ( ! dst | | size > end - dst )
return NULL ;
2016-06-22 19:49:14 +03: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 12:21:04 +03:00
static inline unsigned int dh_data_size ( const struct dh * p )
2016-06-22 19:49:14 +03:00
{
2022-02-21 15:10:49 +03:00
return p - > key_size + p - > p_size + p - > g_size ;
2016-06-22 19:49:14 +03:00
}
2017-09-29 12:21:05 +03:00
unsigned int crypto_dh_key_len ( const struct dh * p )
2016-06-22 19:49:14 +03: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-28 01:36:11 +03:00
u8 * const end = ptr + len ;
2016-06-22 19:49:14 +03:00
struct kpp_secret secret = {
. type = CRYPTO_KPP_SECRET_TYPE_DH ,
. len = len
} ;
2018-07-28 01:36:11 +03:00
if ( unlikely ( ! len ) )
2016-06-22 19:49:14 +03:00
return - EINVAL ;
2018-07-28 01:36:11 +03:00
ptr = dh_pack_data ( ptr , end , & secret , sizeof ( secret ) ) ;
ptr = dh_pack_data ( ptr , end , & params - > key_size ,
sizeof ( params - > key_size ) ) ;
ptr = dh_pack_data ( ptr , end , & params - > p_size , sizeof ( params - > p_size ) ) ;
ptr = dh_pack_data ( ptr , end , & params - > 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 19:49:14 +03: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 15:10:51 +03:00
int __crypto_dh_decode_key ( const char * buf , unsigned int len , struct dh * params )
2016-06-22 19:49:14 +03: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 ( & params - > key_size , ptr , sizeof ( params - > key_size ) ) ;
ptr = dh_unpack_data ( & params - > p_size , ptr , sizeof ( params - > p_size ) ) ;
ptr = dh_unpack_data ( & params - > 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 15:10:51 +03: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 05:30:46 +03: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 15:10:49 +03:00
params - > g_size > params - > p_size )
2017-11-06 05:30:46 +03:00
return - EINVAL ;
2017-11-06 05:30:45 +03: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 19:49:14 +03:00
return 0 ;
}
EXPORT_SYMBOL_GPL ( crypto_dh_decode_key ) ;