Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 18 May 2019 15:20:46 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Christian Lamparter <chunkeey@gmail.com>
Cc:     linux-crypto@vger.kernel.org,
        Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [RFC PATCH] crypto: skcipher - perform len fits into blocksize
 check at the top
Message-ID: <20190518222045.GA3119@sol.localdomain>
References: <20190518213035.21699-1-chunkeey@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190518213035.21699-1-chunkeey@gmail.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Christian,

On Sat, May 18, 2019 at 11:30:35PM +0200, Christian Lamparter wrote:
> This patch adds early check to test the given data length
> is aligned with the supported ciphers blocksize, or abort
> with -EINVAL in case the supplied chunk size does not fit
> without padding into the blocksize for block ciphers.
> 
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> 
> ---
> 
> This will also work instead of the
> "crypto: crypto4xx - blockciphers should only accept complete blocks"
> It will fix all potential driver issues in other drivers as well as
> break the drivers that don't have the correct blocksize set. it will
> also make the extra checks scattered around in the drivers make
> redundand as well as the extra tests that do send incomplete blocks
> to the hardware drivers.
> ---
>  include/crypto/skcipher.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
> index e555294ed77f..971294602a41 100644
> --- a/include/crypto/skcipher.h
> +++ b/include/crypto/skcipher.h
> @@ -494,6 +494,8 @@ static inline int crypto_skcipher_encrypt(struct skcipher_request *req)
>  	crypto_stats_get(alg);
>  	if (crypto_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
>  		ret = -ENOKEY;
> +	else if (!IS_ALIGNED(cryptlen, crypto_skcipher_blocksize(tfm)))
> +		ret = -EINVAL;
>  	else
>  		ret = tfm->encrypt(req);
>  	crypto_stats_skcipher_encrypt(cryptlen, ret, alg);
> @@ -521,6 +523,8 @@ static inline int crypto_skcipher_decrypt(struct skcipher_request *req)
>  	crypto_stats_get(alg);
>  	if (crypto_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
>  		ret = -ENOKEY;
> +	else if (!IS_ALIGNED(cryptlen, crypto_skcipher_blocksize(tfm)))
> +		ret = -EINVAL;
>  	else
>  		ret = tfm->decrypt(req);
>  	crypto_stats_skcipher_decrypt(cryptlen, ret, alg);
> -- 

Unfortunately this doesn't work because there are some skcipher algorithms
("cts" and "adiantum") that set cra_blocksize to their minimum message length
(16) rather than their length alignment requirement (1).  I.e., these algorithms
support all messages with length >= 16 bytes.

So before we can add this check, we need to get this straightened out.

I actually don't think "block size" should be a property of all crypto
algorithms at all, e.g. for skciphers we should instead have "min_msgsize" and
"msgsize_alignment".  The notion of "block size" is not meaningful for
length-preserving encryption algorithms in general, let alone all crypto
algorithms.  But unfortunately "block size" is pretty deeply embedded into the
crypto API, so it doesn't look easy to fix this...  Maybe for skciphers we could
get away with it always meaning the msgsize_alignment, though.

- Eric