From: Andy Lutomirski Subject: Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library Date: Thu, 13 Sep 2018 08:26:05 -0700 Message-ID: References: <20180911010838.8818-1-Jason@zx2c4.com> <20180911010838.8818-3-Jason@zx2c4.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Andy Lutomirski , Ard Biesheuvel , "Jason A. Donenfeld" , LKML , Netdev , David Miller , Greg Kroah-Hartman , Samuel Neves , Jean-Philippe Aumasson , Linux Crypto Mailing List To: Milan Broz Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org > On Sep 12, 2018, at 11:39 PM, Milan Broz wrote: >=20 >> On 13/09/18 01:45, Andy Lutomirski wrote: >> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel > ...=20 >> b) Crypto that is used dynamically. This includes dm-crypt >> (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a >> lot of IPSEC stuff, possibly KCM, and probably many more. These will >> get comparatively little benefit from being converted to a zinc-like >> interface. For some of these cases, it wouldn't make any sense at all >> to convert them. Certainly the ones that do async hardware crypto >> using DMA engines will never look at all like zinc, even under the >> hood. >=20 > Please note, that dm-crypt now uses not only block ciphers and modes, > but also authenticated encryption and hashes (for ESSIV and HMAC > in authenticated composed modes) and RNG (for random IV). > We use crypto API, including async variants (I hope correctly :) Right. And all this is why I don=E2=80=99t think dm-crypt should use zinc, a= t least not any time soon.