linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Cheng-Yi Chiang <cychiang@chromium.org>,
	ecryptfs@vger.kernel.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Guenter Roeck <groeck@chromium.org>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Kamil Konieczny <k.konieczny@samsung.com>,
	keyrings@vger.kernel.org, Krzysztof Kozlowski <krzk@kernel.org>,
	Krzysztof Opasiak <k.opasiak@samsung.com>,
	Lars Persson <lars.persson@axis.com>,
	linux-bluetooth@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org,
	Robert Baldyga <r.baldyga@samsung.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Vladimir Zapolskiy <vz@mleia.com>, Zaibo Xu <xuzaibo@huawei.com>
Subject: [PATCH 01/20] crypto: hash - introduce crypto_shash_tfm_digest()
Date: Fri,  1 May 2020 22:31:03 -0700	[thread overview]
Message-ID: <20200502053122.995648-2-ebiggers@kernel.org> (raw)
In-Reply-To: <20200502053122.995648-1-ebiggers@kernel.org>

From: Eric Biggers <ebiggers@google.com>

Currently the simplest use of the shash API is to use
crypto_shash_digest() to digest a whole buffer.  However, this still
requires allocating a hash descriptor (struct shash_desc).  Many users
don't really want to preallocate one and instead just use a one-off
descriptor on the stack like the following:

	{
		SHASH_DESC_ON_STACK(desc, tfm);
		int err;

		desc->tfm = tfm;

		err = crypto_shash_digest(desc, data, len, out);

		shash_desc_zero(desc);
	}

Wrap this in a new helper function crypto_shash_tfm_digest() that can be
used instead of the above.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/shash.c        | 16 ++++++++++++++++
 include/crypto/hash.h | 19 +++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/crypto/shash.c b/crypto/shash.c
index c075b26c2a1d9f..e6a4b5f39b8c64 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -206,6 +206,22 @@ int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 }
 EXPORT_SYMBOL_GPL(crypto_shash_digest);
 
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out)
+{
+	SHASH_DESC_ON_STACK(desc, tfm);
+	int err;
+
+	desc->tfm = tfm;
+
+	err = crypto_shash_digest(desc, data, len, out);
+
+	shash_desc_zero(desc);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(crypto_shash_tfm_digest);
+
 static int shash_default_export(struct shash_desc *desc, void *out)
 {
 	memcpy(out, shash_desc_ctx(desc), crypto_shash_descsize(desc->tfm));
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index cee446c59497c6..4829d2367eda87 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -855,6 +855,25 @@ int crypto_shash_setkey(struct crypto_shash *tfm, const u8 *key,
 int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 			unsigned int len, u8 *out);
 
+/**
+ * crypto_shash_tfm_digest() - calculate message digest for buffer
+ * @tfm: hash transformation object
+ * @data: see crypto_shash_update()
+ * @len: see crypto_shash_update()
+ * @out: see crypto_shash_final()
+ *
+ * This is a simplified version of crypto_shash_digest() for users who don't
+ * want to allocate their own hash descriptor (shash_desc).  Instead,
+ * crypto_shash_tfm_digest() takes a hash transformation object (crypto_shash)
+ * directly, and it allocates a hash descriptor on the stack internally.
+ * Note that this stack allocation may be fairly large.
+ *
+ * Context: Any context.
+ * Return: 0 on success; < 0 if an error occurred.
+ */
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out);
+
 /**
  * crypto_shash_export() - extract operational state for message digest
  * @desc: reference to the operational state handle whose state is exported
-- 
2.26.2


  reply	other threads:[~2020-05-02  5:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02  5:31 [PATCH 00/20] crypto: introduce crypto_shash_tfm_digest() Eric Biggers
2020-05-02  5:31 ` Eric Biggers [this message]
2020-05-02  5:31 ` [PATCH 02/20] crypto: arm64/aes-glue - use crypto_shash_tfm_digest() Eric Biggers
2020-05-02  5:31 ` [PATCH 03/20] crypto: essiv " Eric Biggers
2020-05-02  5:31 ` [PATCH 04/20] crypto: artpec6 " Eric Biggers
2020-05-02  5:31 ` [PATCH 05/20] crypto: ccp " Eric Biggers
2020-05-07 21:23   ` Tom Lendacky
2020-05-02  5:31 ` [PATCH 06/20] crypto: ccree " Eric Biggers
2020-05-03 14:01   ` Gilad Ben-Yossef
2020-05-02  5:31 ` [PATCH 07/20] crypto: hisilicon/sec2 " Eric Biggers
2020-05-02  5:31 ` [PATCH 08/20] crypto: mediatek " Eric Biggers
2020-05-02  5:31 ` [PATCH 09/20] crypto: n2 " Eric Biggers
2020-05-02  5:31 ` [PATCH 10/20] crypto: omap-sham " Eric Biggers
2020-05-02  5:31 ` [PATCH 11/20] crypto: s5p-sss " Eric Biggers
2020-05-05 14:19   ` Krzysztof Kozlowski
2020-05-02  5:31 ` [PATCH 12/20] nfc: s3fwrn5: " Eric Biggers
2020-05-02  5:31 ` [PATCH 13/20] fscrypt: " Eric Biggers
2020-05-02  5:31 ` [PATCH 14/20] ecryptfs: " Eric Biggers
2020-05-02  5:31 ` [PATCH 15/20] nfsd: " Eric Biggers
2020-05-04 19:09   ` J. Bruce Fields
2020-05-02  5:31 ` [PATCH 16/20] ubifs: " Eric Biggers
2020-05-02  5:31 ` [PATCH 17/20] Bluetooth: " Eric Biggers
2020-05-02  5:31 ` [PATCH 18/20] sctp: " Eric Biggers
2020-05-02  5:31 ` [PATCH 19/20] KEYS: encrypted: " Eric Biggers
2020-05-02  5:31 ` [PATCH 20/20] ASoC: cros_ec_codec: " Eric Biggers
2020-05-02  6:44 ` [PATCH 00/20] crypto: introduce crypto_shash_tfm_digest() Marcel Holtmann
2020-05-03 16:13 ` Ard Biesheuvel
2020-05-08  6:07 ` 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=20200502053122.995648-2-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=cychiang@chromium.org \
    --cc=ecryptfs@vger.kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=gilad@benyossef.com \
    --cc=groeck@chromium.org \
    --cc=jesper.nilsson@axis.com \
    --cc=k.konieczny@samsung.com \
    --cc=k.opasiak@samsung.com \
    --cc=keyrings@vger.kernel.org \
    --cc=krzk@kernel.org \
    --cc=lars.persson@axis.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=r.baldyga@samsung.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vz@mleia.com \
    --cc=xuzaibo@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).