Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11A45C74A44 for ; Sat, 11 Mar 2023 08:06:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229744AbjCKIGY (ORCPT ); Sat, 11 Mar 2023 03:06:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbjCKIGX (ORCPT ); Sat, 11 Mar 2023 03:06:23 -0500 Received: from 167-179-156-38.a7b39c.syd.nbn.aussiebb.net (167-179-156-38.a7b39c.syd.nbn.aussiebb.net [167.179.156.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B23112B3CC for ; Sat, 11 Mar 2023 00:06:22 -0800 (PST) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1pauF6-002wnO-Ll; Sat, 11 Mar 2023 16:06:17 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Sat, 11 Mar 2023 16:06:16 +0800 Date: Sat, 11 Mar 2023 16:06:16 +0800 From: Herbert Xu To: Ard Biesheuvel Cc: linux-crypto@vger.kernel.org, ebiggers@kernel.org, James Bottomley Subject: Re: [PATCH v2] crypto: lib - implement library version of AES in CFB mode Message-ID: References: <20230217144348.1537615-1-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Mar 10, 2023 at 05:18:05PM +0100, Ard Biesheuvel wrote: > > Does that mean you are bringing back blkcipher? I think that would the > right thing to do tbh, although it might make sense to enhance > skcipher (and aead) to support this. I haven't gone into that kind of detail yet but my first impression is that it would be the analogue of shash and skcipher would simply wrap around it just like ahash wraps around shash. > Could we perhaps update struct skcipher_request so it can describe > virtually mapped address ranges, but permit this only for synchronous > implementations? Then, we could update the skcipher walker code to > produce a single walk step covering the entire range, and just use the > provided virtual addresses directly, rather than going through a > mapping interface? Since skcipher doesn't actually need to carry any state with it I'd like to avoid having an skcipher_request at all. So it would look pretty much like the existing crypto_cipher interface except with the addition of length and IV. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt