From: Paul Crowley Subject: Re: [RFC PATCH 3/9] crypto: chacha20-generic - refactor to allow varying number of rounds Date: Mon, 6 Aug 2018 18:06:27 -0700 Message-ID: References: <20180806223300.113891-1-ebiggers@kernel.org> <20180806223300.113891-4-ebiggers@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: ebiggers@kernel.org, linux-crypto@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Herbert Xu , Greg Kaiser , Michael Halcrow , samuel.c.p.neves@gmail.com, tomer.ashur@esat.kuleuven.be, Eric Biggers , djb@cr.yp.to To: Jason@zx2c4.com Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org We've done enough performance testing to know that the short answer is: HPolyC is still a lot slower than I'm happy with, and encryption still has a quite noticeable effect on the feel of low end devices. Indeed, this proposal may change if I find a faster way to do the first and last rounds. We don't know how long chipsets without hardware AES will be around, but especially in this post-Moore's Law era, I'd bet on Schneier's maxim: the low end doesn't go away, and if a day comes where we don't have to worry about this in handsets, we'll probably be worrying about it for IoT devices. On Mon, 6 Aug 2018 at 17:15, Jason A. Donenfeld wrote: > > Hi Paul, > > On 8/6/18, Paul Crowley wrote: > > Salsa20 was one of the earlier ARX proposals, and set a very > > conservative number of rounds as befits our state of knowledge at the > > time. Since then we've learned a lot more about cryptanalysis of such > > offerings, and I think we can be comfortable with fewer rounds. The > > best attack on ChaCha breaks 7 rounds, and that attack requires 2^248 > > operations. Every round of ChaCha makes attacks vastly harder. > > I'm well aware of that, which is why I mentioned that ChaCha12 > _probably_ has an adequate security. My primary concerns are a bit > different actually from where you're going - that it breaks from > what's becoming a pretty widely accepted "norm" and, more importantly, > that it increases implementation complexity. These aren't really > drastic concerns, but I am in earnest wondering the type of hardware > analysis you did to determine that you really do need the 12-speedup. > What's the practical landscape out there look like? What disk speeds > were too low for which specific kind of Android usage on which > particular hardware? Did you hit the bottlenecks when paging for code > or when filling up caches when writing asynchronously? And for how > much longer do you foresee underpowered hardware like that being a not > insignificant part of the market? I'm especially curious to know > because ostensibly at Google you have all sorts metrics regarding that > kind of thing. > > Jason