Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Stephan Mueller <smueller@chronox.de>
To:     Ondrej =?utf-8?B?TW9zbsOhxI1law==?= <omosnacek@gmail.com>
Cc:     linux-crypto@vger.kernel.org,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Sahana Prasad <saprasad@redhat.com>,
        Tomas Mraz <tmraz@redhat.com>, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: libkcapi tests are failing on kernels 5.5+
Date:   Tue, 21 Apr 2020 11:19:36 +0200
Message-ID: <7154254.Uj1dk3xSE7@tauon.chronox.de>
In-Reply-To: <CAAUqJDvZt7_j+eor1sXRg+QmrdXTjMiymFnji86PoatsYPUugA@mail.gmail.com>
References: <CAAUqJDvZt7_j+eor1sXRg+QmrdXTjMiymFnji86PoatsYPUugA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Am Dienstag, 21. April 2020, 10:08:14 CEST schrieb Ondrej Mosn=C3=A1=C4=8De=
k:

Hi Ondrej,

> Hi all,
>=20
> the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> All encryption/decryption tests that use 'ctr(aes)' and a message size
> that is not a multiple of 16 fail due to kcapi-enc returning different
> output than expected.

Confirmed.

On the recent kernels, the data generated by kcapi-enc contains trailing ze=
ro=20
bytes for data that is a fraction of the block size.

I think the issue is in the following kernel code in _skcipher_recvmsg:

        unsigned int bs =3D crypto_skcipher_chunksize(tfm);

        /*
         * If more buffers are to be expected to be processed, process only
         * full block size buffers.
         */
        if (ctx->more || len < ctx->used)
                len -=3D len % bs;


The kernel truncates the size to be processed to the chunk size. As the=20
chunksize returns the block size of the underlying cipher (e.g. AES -> 16),=
=20
the kernel code will not process non-aligned data.

Herbert, could you help me identifying what exactly was the root cause for =
the=20
patch 5b0fe9552336338acb52756daf65dd7a4eeca73f ? I.e. it seems that stream=
=20
ciphers made out of a block cipher would not generate the data part that is=
 a=20
fraction of the block size (e.g. CTR, CTS).

Ciao
Stephan