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:     Ard Biesheuvel <ardb@kernel.org>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: ARM CE: CTS IV handling
Date:   Tue, 19 May 2020 19:35:22 +0200
Message-ID: <8691076.XE7dyB1q2z@tauon.chronox.de>
In-Reply-To: <CAMj1kXHscmtLq=tA7zUgiNqZYgTFjfREL5EK6ZnoDCFp52GWGw@mail.gmail.com>
References: <4311723.JCXmkh6OgN@tauon.chronox.de> <CAMj1kXHscmtLq=tA7zUgiNqZYgTFjfREL5EK6ZnoDCFp52GWGw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:

Hi Ard,

> 
> To be honest, this looks like the API is being used incorrectly. Is
> this a similar issue to the one Herbert spotted recently with the CTR
> code?
> 
> When you say 'leaving the TFM untouched' do you mean the skcipher
> request? The TFM should not retain any per-request state in the first
> place.
> 
> The skcipher request struct is not meant to retain any state either -
> the API simply does not support incremental encryption if the input is
> not a multiple of the chunksize.
> 
> Could you give some sample code on how you are using the API in this case?

What I am doing technically is to allocate a new tfm and request at the 
beginning and then reuse the TFM and request. In that sense, I think I violate 
that constraint.

But in order to implement such repetition, I can surely clear / allocate a new 
TFM. But in order to get that right, I need the resulting IV after the cipher 
operation.

This IV that I get after the cipher operation completes is different between C 
and CE.

Ciao
Stephan