On Tue, Jan 17, 2017 at 09:20:11AM +, Ard Biesheuvel wrote:
>
> So to be clear, it is part of the API that after calling
> crypto_skcipher_encrypt(req), and completing the request, req->iv
> should contain a value that could potentially be used to encrypt
> additional data? That sounds highly
On Tue, Jan 17, 2017 at 09:30:30AM +, Ard Biesheuvel wrote:
>
> Got a link?
http://lkml.iu.edu/hypermail/linux/kernel/1506.2/00346.html
> OK, so that means chaining skcipher_set_crypt() calls, where req->iv
> is passed on between requests? Are there chaining modes beyond
> cts(cbc)
On Mon, Jan 16, 2017 at 09:16:35AM +, Ard Biesheuvel wrote:
> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
> cts - Convert to skcipher"), the cts code tacitly assumes that
> the underlying CBC encryption transform performed on the first
> part of the plaintext returns an IV
On 17 January 2017 at 09:25, Herbert Xu wrote:
> On Tue, Jan 17, 2017 at 09:20:11AM +, Ard Biesheuvel wrote:
>>
>> So to be clear, it is part of the API that after calling
>> crypto_skcipher_encrypt(req), and completing the request, req->iv
>> should contain a
On 17 January 2017 at 09:11, Herbert Xu wrote:
> On Mon, Jan 16, 2017 at 09:16:35AM +, Ard Biesheuvel wrote:
>> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
>> cts - Convert to skcipher"), the cts code tacitly assumes that
>> the underlying CBC
Since the skcipher conversion in commit 0605c41cc53c ("crypto:
cts - Convert to skcipher"), the cts code tacitly assumes that
the underlying CBC encryption transform performed on the first
part of the plaintext returns an IV in req->iv that is suitable
for encrypting the final bit.
While this is