From: Binoy Jayan Subject: Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt Date: Wed, 18 Jan 2017 22:39:45 +0530 Message-ID: References: <20170113104128.GA23497@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Herbert Xu , linux-crypto@vger.kernel.org, dm-devel@redhat.com, Mike Snitzer , Milan Broz , Mikulas Patocka To: =?UTF-8?B?T25kcmVqIE1vc27DocSNZWs=?= , Arnd Bergmann , Mark Brown Return-path: Received: from mail-ua0-f174.google.com ([209.85.217.174]:34849 "EHLO mail-ua0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbdARRKK (ORCPT ); Wed, 18 Jan 2017 12:10:10 -0500 Received: by mail-ua0-f174.google.com with SMTP id y9so14219985uae.2 for ; Wed, 18 Jan 2017 09:09:47 -0800 (PST) In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: Hi Milan, On 13 January 2017 at 17:31, Ondrej Mosn=C3=A1=C4=8Dek wrote: > 2017-01-13 11:41 GMT+01:00 Herbert Xu : >> On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote: >>> the goal of this patchset is to allow those skcipher API users that nee= d to >>> process batches of small messages (especially dm-crypt) to do so effici= ently. >> >> Please explain why this can't be done with the existing framework >> using IV generators similar to the ones used for IPsec. > > As I already mentioned in another thread, there are basically two reasons= : > > 1) Milan would like to add authenticated encryption support to > dm-crypt (see [1]) and as part of this change, a new random IV mode > would be introduced. This mode generates a random IV for each sector > write, includes it in the authenticated data and stores it in the > sector's metadata (in a separate part of the disk). In this case > dm-crypt will need to have control over the IV generation (or at least > be able to somehow retrieve it after the crypto operation... but > passing RNG responsibility to drivers doesn't seem to be a good idea > anyway). > > 2) With this API, drivers wouldn't have to provide implementations for > specific IV generation modes, and just implement bulk requests for the > common modes/algorithms (XTS, CBC, ...) while still getting > performance benefit. I just sent out v3 for the dm-crypt changes I was working on. I came across your patches for authenticated encryption support. Although I haven't looked at it entirely, I was wondering how it could be put together including the points Ondrej was mentioning. Will look at it more. Please keep me in cc when you send out the next revision if that is possible. Thanks, Binoy