mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Nicolai Stange <nstange@suse.de>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>
Cc: "Stephan Müller" <smueller@chronox.de>,
	"Torsten Duwe" <duwe@suse.de>,
	"David Howells" <dhowells@redhat.com>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v4 05/15] crypto: dh - split out deserialization code from crypto_dh_decode()
Date: Mon, 21 Feb 2022 15:13:46 +0100	[thread overview]
Message-ID: <58407bcf-002a-72e9-0a51-04a2a410fb5a@suse.de> (raw)
In-Reply-To: <20220221121101.1615-6-nstange@suse.de>

On 2/21/22 13:10, Nicolai Stange wrote:
> 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>
> ---
>   crypto/dh_helper.c  | 27 +++++++++++++++++++--------
>   include/crypto/dh.h | 16 ++++++++++++++++
>   2 files changed, 35 insertions(+), 8 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

  reply	other threads:[~2022-02-21 14:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 12:10 [PATCH v4 00/15] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance Nicolai Stange
2022-02-21 12:10 ` [PATCH v4 01/15] crypto: kpp - provide support for KPP template instances Nicolai Stange
2022-02-21 13:18   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 02/15] crypto: kpp - provide support for KPP spawns Nicolai Stange
2022-02-21 14:11   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 03/15] crypto: dh - remove struct dh's ->q member Nicolai Stange
2022-02-21 12:10 ` [PATCH v4 04/15] crypto: dh - constify struct dh's pointer members Nicolai Stange
2022-02-21 14:12   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 05/15] crypto: dh - split out deserialization code from crypto_dh_decode() Nicolai Stange
2022-02-21 14:13   ` Hannes Reinecke [this message]
2022-02-21 12:10 ` [PATCH v4 06/15] crypto: dh - introduce common code for built-in safe-prime group support Nicolai Stange
2022-02-21 14:14   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 07/15] crypto: dh - implement ffdheXYZ(dh) templates Nicolai Stange
2022-02-21 14:15   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 08/15] crypto: testmgr - add known answer tests for " Nicolai Stange
2022-02-21 14:16   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 09/15] crypto: dh - implement private key generation primitive for ffdheXYZ(dh) Nicolai Stange
2022-02-21 14:17   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 10/15] crypto: testmgr - add keygen tests for ffdheXYZ(dh) templates Nicolai Stange
2022-02-21 14:18   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 11/15] crypto: dh - allow for passing NULL to the ffdheXYZ(dh)s' ->set_secret() Nicolai Stange
2022-02-21 14:18   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 12/15] crypto: api - allow algs only in specific constructions in FIPS mode Nicolai Stange
2022-02-21 14:19   ` Hannes Reinecke
2022-02-21 12:10 ` [PATCH v4 13/15] crypto: dh - disallow plain "dh" usage " Nicolai Stange
2022-02-21 14:19   ` Hannes Reinecke
2022-02-21 12:11 ` [PATCH v4 14/15] lib/mpi: export mpi_rshift Nicolai Stange
2022-02-21 12:11 ` [PATCH v4 15/15] crypto: dh - calculate Q from P for the full public key verification Nicolai Stange
2022-02-21 14:20   ` Hannes Reinecke
2022-03-02 22:58 ` [PATCH v4 00/15] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58407bcf-002a-72e9-0a51-04a2a410fb5a@suse.de \
    --to=hare@suse.de \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=duwe@suse.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nstange@suse.de \
    --cc=smueller@chronox.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®