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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 096B3C433EF for ; Thu, 27 Jan 2022 05:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7+3B06ukKVnZrNPtrAQJiLb83yRFw3Ph5b02Vonwj7Y=; b=GPfyHK8vWfnVkc GU8b6ylcdFSx9QkwloQECzeUDH3+6GYUquztBihGW7bWlPUgHcqRD2sU38eSXc4ReizGk35TIpG93 4Y/PiNqHaQjtYsiJ+IdgSKXgyz5N81sSAhPI3SL7mhC2MSLlHsoONLYFKFc/5rv5gUBd/Gc1SIT0n GT7XO51tDBLywwJFxps8YiC4Ym9/XY/lija4tnYrgnHJNA/MSzClZQv3BfRIJxfsZoReui/5ptEh4 lO82+jQkMAfWvi7RoY0i0Qg9nv3crIeTFGADeNNV0TmS//bLkYubw3DCh+5EEdqDzVpPLDErryLZu gyaRE0udXLobXlGEmViA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCxKf-00EOhK-7F; Thu, 27 Jan 2022 05:28:29 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCxKb-00EOgq-BG for linux-arm-kernel@lists.infradead.org; Thu, 27 Jan 2022 05:28:26 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E1BE76184D; Thu, 27 Jan 2022 05:28:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24876C340E4; Thu, 27 Jan 2022 05:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643261304; bh=Q3qF/5ZWSe6syjSmD536S8sOy5+4UjHleenLI0y9wII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bK0TwYHPfH8OB0szVwIQkYECazWi3ziRUPF46fKzmPdjkPpKYTSBeOyQg8gItdPRo oR3TR1I6K6a9teMbrakntH7rCyoEQrZ30qH+QkZD8MFRa49miWqzbgfQ7Ta94ZlkP2 1iOwAqkh2BYZstHgo0hALFOYXRaKP9EAme3KiX28emeR+8JBaT261SLg+9/wUnv6ip HRBxU2B3RDse0/aWwyFa1ef071/yFjLKJmN2/JqpyC7bP7EZo0l3r+DwbKOC1v+KiC Tjslc69U7s09saZGaYe4H2O+IswpQbUyfLDx1XCTeTr8sctrt9CEukW4p9xa+kFljm 2VSZ9LgN0ADQQ== Date: Wed, 26 Jan 2022 21:28:22 -0800 From: Eric Biggers To: Nathan Huckleberry Cc: linux-crypto@vger.kernel.org, Herbert Xu , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Paul Crowley , Sami Tolvanen Subject: Re: [RFC PATCH 1/7] crypto: xctr - Add XCTR support Message-ID: References: <20220125014422.80552-1-nhuck@google.com> <20220125014422.80552-2-nhuck@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220125014422.80552-2-nhuck@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220126_212825_478290_46352FDF X-CRM114-Status: GOOD ( 18.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jan 24, 2022 at 07:44:16PM -0600, Nathan Huckleberry wrote: > Add a generic implementation of XCTR mode as a template. XCTR is a > blockcipher mode similar to CTR mode. XCTR uses XORs and little-endian > addition rather than big-endian arithmetic which makes it slightly > faster on little-endian CPUs. It is used as a component to implement > HCTR2. > > > More information on XCTR mode can be found in the HCTR2 paper: > https://eprint.iacr.org/2021/1441.pdf The other advantage (besides being faster on little-endian CPUs) of XCTR over CTR is that on practical input sizes, XCTR never needs to deal with integer overflows, and therefore is less likely to be implemented incorrectly. It is in the paper, but it's worth emphasizing. > +static void crypto_xctr_crypt_final(struct skcipher_walk *walk, > + struct crypto_cipher *tfm, u32 byte_ctr) > +{ > + unsigned int bsize = crypto_cipher_blocksize(tfm); > + unsigned long alignmask = crypto_cipher_alignmask(tfm); > + u8 ctr[MAX_CIPHER_BLOCKSIZE]; > + u8 ctrblk[MAX_CIPHER_BLOCKSIZE]; > + u8 tmp[MAX_CIPHER_BLOCKSIZE + MAX_CIPHER_ALIGNMASK]; > + u8 *keystream = PTR_ALIGN(tmp + 0, alignmask + 1); > + u8 *src = walk->src.virt.addr; > + u8 *dst = walk->dst.virt.addr; > + unsigned int nbytes = walk->nbytes; > + u32 ctr32 = byte_ctr / bsize + 1; > + > + u32_to_le_block(ctr, ctr32, bsize); > + crypto_xor_cpy(ctrblk, ctr, walk->iv, bsize); > + crypto_cipher_encrypt_one(tfm, keystream, ctrblk); > + crypto_xor_cpy(dst, keystream, src, nbytes); > +} How about limiting it to a 16-byte block size for now? That would simplify the implementation. You can enforce the block size in crypto_xctr_create(). > +static struct crypto_template crypto_xctr_tmpl[] = { > + { > + .name = "xctr", > + .create = crypto_xctr_create, > + .module = THIS_MODULE, > + } > +}; This is defining an array containing 1 crypto_template. It should just define a crypto_template struct on its own (not an array). - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel