From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41DD6C4361A for ; Fri, 4 Dec 2020 17:36:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E590229C4 for ; Fri, 4 Dec 2020 17:36:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388372AbgLDRgm (ORCPT ); Fri, 4 Dec 2020 12:36:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:39186 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726254AbgLDRgl (ORCPT ); Fri, 4 Dec 2020 12:36:41 -0500 X-Gm-Message-State: AOAM530lYNSiOfOYX3WfNLis5YpyxGOItX23T/Zomz7IjRcgfOtm/QJc 7kOgzWySY9XAyMia6QPCIJnoxJ8rG7nyDozDskU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607103360; bh=nzOPWzsALGm9g96B6OfU76fRBhiHX0cmH9B2INe3Q4I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ig1oMzSXyhdIbA9js/0zEH5KavGr3idC/dJT8rM75LAdwf0sLCyFFeL6uFKbDX5Q2 HzusRHGuh9tiXURDyTSTsFXM2actfCmvzS3EWsmPGcWHuxeSx4+XW/XyUAXc/dGSjW 0qIH0PoOa7WI4p0mHmUTCYI3J2hIuvBsg7U6hk4fHDBe8PvnNAhyIBlb8eNRshvsKG e5AxtFETFlv7CoQqu6Ta+4jembBa+jRqgWkaiA0VjeT1mNajL5tTHQwqNY/1GY6+Kv CMEoj8qt0kgOlVXPGfxfwAbOnImsvxTu/PFkdrYTZkSy2eFaO2eRk0Uc486CIIhyCX Agp7ec8rwAWHg== X-Google-Smtp-Source: ABdhPJznC6r+tZ49KMWbvmkRQRkw7RbodUPNa/S/eN750bh5EDuKqJYhR44eXH+qljWAdk/oc/WNBhTWFufK1T560JQ= X-Received: by 2002:a05:6830:214c:: with SMTP id r12mr4423697otd.90.1607103359560; Fri, 04 Dec 2020 09:35:59 -0800 (PST) MIME-Version: 1.0 References: <20201204154626.GA26255@fieldses.org> <2F96670A-58DC-43A6-A20E-696803F0BFBA@oracle.com> <160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk> <118876.1607093975@warthog.procyon.org.uk> <122997.1607097713@warthog.procyon.org.uk> <20201204160347.GA26933@fieldses.org> <125709.1607100601@warthog.procyon.org.uk> <127458.1607102368@warthog.procyon.org.uk> In-Reply-To: <127458.1607102368@warthog.procyon.org.uk> From: Ard Biesheuvel Date: Fri, 4 Dec 2020 18:35:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Why the auxiliary cipher in gss_krb5_crypto.c? To: David Howells Cc: Bruce Fields , Chuck Lever , CIFS , Linux NFS Mailing List , Herbert Xu , "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" , Linux Kernel Mailing List , Trond Myklebust , Linux Crypto Mailing List , linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Dec 2020 at 18:19, David Howells wrote: > > Ard Biesheuvel wrote: > > > The tricky thing with CTS is that you have to ensure that the final > > full and partial blocks are presented to the crypto driver as one > > chunk, or it won't be able to perform the ciphertext stealing. This > > might be the reason for the current approach. If the sunrpc code has > > multiple disjoint chunks of data to encrypto, it is always better to > > wrap it in a single scatterlist and call into the skcipher only once. > > Yeah - the problem with that is that for sunrpc, we might be dealing with 1MB > plus bits of non-contiguous pages, requiring >8K of scatterlist elements > (admittedly, we can chain them, but we may have to do one or more large > allocations). > > > However, I would recommend against it: > > Sorry, recommend against what? > Recommend against the current approach of manipulating the input like this and feeding it into the skcipher piecemeal. Herbert recently made some changes for MSG_MORE support in the AF_ALG code, which permits a skcipher encryption to be split into several invocations of the skcipher layer without the need for this complexity on the side of the caller. Maybe there is a way to reuse that here. Herbert? > > at least for ARM and arm64, I > > have already contributed SIMD based implementations that use SIMD > > permutation instructions and overlapping loads and stores to perform > > the ciphertext stealing, which means that there is only a single layer > > which implements CTS+CBC+AES, and this layer can consume the entire > > scatterlist in one go. We could easily do something similar in the > > AES-NI driver as well. > > Can you point me at that in the sources? > arm64 has arch/arm64/crypto/aes-glue.c arch/arm64/crypto/aes-modes.S where the former implements the skcipher wrapper for an implementation of "cts(cbc(aes))" static int cts_cbc_encrypt(struct skcipher_request *req) walks over the src/dst scatterlist and feeds the data into the asm helpers, one for the bulk of the input, and one for the final full and partial blocks (or two final full blocks) The SIMD asm helpers are aes_cbc_encrypt aes_cbc_decrypt aes_cbc_cts_encrypt aes_cbc_cts_decrypt > Can you also do SHA at the same time in the same loop? > SHA-1 or HMAC-SHA1? The latter could probably be modeled as an AEAD. The former doesn't really fit the current API so we'd have to invent something for it. > Note that the rfc3962 AES does the checksum over the plaintext, but rfc8009 > does it over the ciphertext. > > David >