From: Paul Crowley Subject: Re: [PATCH v2 0/5] crypto: Speck support Date: Thu, 26 Apr 2018 16:30:05 +0000 Message-ID: References: <20180212235209.117393-1-ebiggers@google.com> <20180424181623.GA174675@google.com> <20180424224734.GA109345@google.com> <20180425194919.GA79662@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: noloader@gmail.com, Jason@zx2c4.com, Greg Kaiser , Herbert Xu , Eric Biggers , Michael Halcrow , Ard Biesheuvel , Patrik Torstensson , Alex Cope , Paul Lawrence , linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org, gregkh@linuxfoundation.org, tashur@esat.kuleuven.be, linux-arm-kernel@lists.infradead.org To: samuel.c.p.neves@gmail.com Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: linux-crypto.vger.kernel.org > Oh, OK, that sounds like something resembling Naor-Reingold or its > relatives. That would work, but with 3 or 4 passes I guess it wouldn't > be very fast. It most resembles HCH mode https://eprint.iacr.org/2007/028 using two passes of Poly1305, one pass of ChaCha20, and one invocation of a 128-bit block cipher for the entire block. I have a writeup with a proof that it's a secure tweakable SPRP, but we haven't actually implemented it yet so the "Performance" section is a bit thin. From published benchmarks, Poly1305 is around 2.3 cpb and ChaCha12 around 4.5 cbp on our target platform, so we're hoping to achieve something a little over 7.1 cpb. Right now we're in a situation where the people who can afford higher-end devices with ARM CE get AES encryption, and the rest of the world gets no encryption, or optional encryption that is rarely enabled because of the performance cost. It's important to me to change that, and right now Speck still looks like a good choice for achieving that end.