linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH 1/3] crypto: skcipher - Add final chunk size field for chaining
Date: Fri, 12 Jun 2020 14:15:52 +0200	[thread overview]
Message-ID: <1688262.LSb4nGpegl@tauon.chronox.de> (raw)
In-Reply-To: <E1jjiTA-0005BO-9n@fornost.hmeau.com>

Am Freitag, 12. Juni 2020, 14:07:36 CEST schrieb Herbert Xu:

Hi Herbert,

> Crypto skcipher algorithms in general allow chaining to break
> large operations into smaller ones based on multiples of the chunk
> size.  However, some algorithms don't support chaining while others
> (such as cts) only support chaining for the leading blocks.
> 
> This patch adds the necessary API support for these algorithms.  In
> particular, a new request flag CRYPTO_TFM_REQ_MORE is added to allow
> chaining for algorithms such as cts that cannot otherwise be chained.
> 
> A new algorithm attribute fcsize has also been added to indicate
> how many blocks at the end of a request that cannot be chained and
> therefore must be withheld if chaining is attempted.
> 
> This attribute can also be used to indicate that no chaining is
> allowed.  Its value should be set to -1 in that case.

Thanks for the patch set.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
> 
>  include/crypto/skcipher.h |   24 ++++++++++++++++++++++++
>  include/linux/crypto.h    |    1 +
>  2 files changed, 25 insertions(+)
> 
> diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
> index 141e7690f9c31..8b864222e6ce4 100644
> --- a/include/crypto/skcipher.h
> +++ b/include/crypto/skcipher.h
> @@ -97,6 +97,8 @@ struct crypto_sync_skcipher {
>   * @walksize: Equal to the chunk size except in cases where the algorithm
> is * 	      considerably more efficient if it can operate on multiple
> chunks * 	      in parallel. Should be a multiple of chunksize.
> + * @fcsize: Number of bytes that must be processed together at the end.
> + *	     If set to -1 then chaining is not possible.
>   * @base: Definition of a generic crypto algorithm.
>   *
>   * All fields except @ivsize are mandatory and must be filled.
> @@ -114,6 +116,7 @@ struct skcipher_alg {
>  	unsigned int ivsize;
>  	unsigned int chunksize;
>  	unsigned int walksize;
> +	int fcsize;
> 
>  	struct crypto_alg base;
>  };
> @@ -279,6 +282,11 @@ static inline unsigned int
> crypto_skcipher_alg_chunksize( return alg->chunksize;
>  }
> 
> +static inline int crypto_skcipher_alg_fcsize(struct skcipher_alg *alg)
> +{
> +	return alg->fcsize;
> +}
> +
>  /**
>   * crypto_skcipher_chunksize() - obtain chunk size
>   * @tfm: cipher handle
> @@ -296,6 +304,22 @@ static inline unsigned int crypto_skcipher_chunksize(
>  	return crypto_skcipher_alg_chunksize(crypto_skcipher_alg(tfm));
>  }
> 
> +/**
> + * crypto_skcipher_fcsize() - obtain number of final bytes
> + * @tfm: cipher handle
> + *
> + * For algorithms such as CTS the final chunks cannot be chained.
> + * This returns the number of final bytes that must be withheld
> + * when chaining.
> + *
> + * Return: number of final bytes
> + */
> +static inline unsigned int crypto_skcipher_fcsize(
> +	struct crypto_skcipher *tfm)
> +{
> +	return crypto_skcipher_alg_fcsize(crypto_skcipher_alg(tfm));

Don't we have an implicit signedness conversion here? int -> unsigned int?
> +}
> +
>  static inline unsigned int crypto_sync_skcipher_blocksize(
>  	struct crypto_sync_skcipher *tfm)
>  {
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 763863dbc079a..d80dccf472595 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -110,6 +110,7 @@
>  #define CRYPTO_TFM_REQ_FORBID_WEAK_KEYS	0x00000100
>  #define CRYPTO_TFM_REQ_MAY_SLEEP	0x00000200
>  #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
> +#define CRYPTO_TFM_REQ_MORE		0x00000800
> 
>  /*
>   * Miscellaneous stuff.


Ciao
Stephan



  reply	other threads:[~2020-06-12 12:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 19:02 [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Ard Biesheuvel
2020-05-19 19:02 ` [RFC/RFT PATCH 1/2] crypto: arm64/aes - align output IV with generic CBC-CTS driver Ard Biesheuvel
2020-05-19 19:02 ` [RFC/RFT PATCH 2/2] crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing Ard Biesheuvel
2020-05-19 19:04 ` [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Ard Biesheuvel
2020-05-20  6:03 ` Stephan Mueller
2020-05-20  6:40   ` Ard Biesheuvel
2020-05-20  6:47     ` Stephan Mueller
2020-05-20  6:54       ` Ard Biesheuvel
2020-05-20  7:01         ` Stephan Mueller
2020-05-20  7:09           ` Ard Biesheuvel
2020-05-21 13:01             ` Gilad Ben-Yossef
2020-05-21 13:23               ` Ard Biesheuvel
2020-05-23 18:52                 ` Stephan Müller
2020-05-23 22:40                   ` Ard Biesheuvel
2020-05-28  7:33 ` Herbert Xu
2020-05-28  8:33   ` Ard Biesheuvel
2020-05-29  8:05     ` Herbert Xu
2020-05-29  8:20       ` Ard Biesheuvel
2020-05-29 11:51         ` Herbert Xu
2020-05-29 12:00           ` Ard Biesheuvel
2020-05-29 12:02             ` Herbert Xu
2020-05-29 13:10               ` Ard Biesheuvel
2020-05-29 13:19                 ` Herbert Xu
2020-05-29 13:41                   ` Ard Biesheuvel
2020-05-29 13:42                     ` Herbert Xu
2020-06-12 12:06                       ` [PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Herbert Xu
2020-06-12 12:07                         ` [PATCH 1/3] crypto: skcipher - Add final chunk size field for chaining Herbert Xu
2020-06-12 12:15                           ` Stephan Mueller [this message]
2020-06-12 12:16                             ` Herbert Xu
2020-06-12 12:21                               ` [v2 PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Herbert Xu
2020-06-12 12:21                                 ` [v2 PATCH 1/3] crypto: skcipher - Add final chunk size field for chaining Herbert Xu
2020-06-12 12:21                                 ` [v2 PATCH 2/3] crypto: algif_skcipher - Add support for fcsize Herbert Xu
2020-06-12 12:21                                 ` [v2 PATCH 3/3] crypto: cts - Add support for chaining Herbert Xu
2020-06-12 16:10                                 ` [v2 PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Ard Biesheuvel
2020-06-15  7:30                                   ` Herbert Xu
2020-06-15  7:50                                     ` Ard Biesheuvel
2020-06-15 18:50                                       ` Eric Biggers
2020-06-15 23:18                                         ` Ard Biesheuvel
2020-06-16 11:04                                         ` Herbert Xu
2020-06-16 16:53                                           ` Eric Biggers
2020-06-12 12:07                         ` [PATCH 2/3] crypto: algif_skcipher - Add support for fcsize Herbert Xu
2020-06-12 12:07                         ` [PATCH 3/3] crypto: cts - Add support for chaining 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=1688262.LSb4nGpegl@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /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).