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]

Message-ID: <CAHmME9o6XQ+16d4b8+BiQViSiOOApi-J_ML2UOOBpTN8hV3iVA@mail.gmail.com>
Date:   Mon, 6 Aug 2018 20:15:43 -0400
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Paul Crowley <paulcrowley@...gle.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

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