linux-kernel - Re: [RFC PATCH 3/9] crypto: chacha20-generic - refactor to allow varying number of rounds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Aug 2018 18:06:27 -0700
From:   Paul Crowley <paulcrowley@...gle.com>
To:     Jason@...c4.com
Cc:     ebiggers@...nel.org, linux-crypto@...r.kernel.org,
        linux-fscrypt@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Greg Kaiser <gkaiser@...gle.com>,
        Michael Halcrow <mhalcrow@...gle.com>,
        samuel.c.p.neves@...il.com, tomer.ashur@...t.kuleuven.be,
        Eric Biggers <ebiggers@...gle.com>, djb@...yp.to
Subject: Re: [RFC PATCH 3/9] crypto: chacha20-generic - refactor to allow
 varying number of rounds

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 <Jason@...c4.com> wrote:
>
> Hi Paul,
>
> On 8/6/18, Paul Crowley <paulcrowley@...gle.com> 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