lkml.org 
[lkml]   [2018]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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@zx2c4.com> wrote:
    >
    > Hi Paul,
    >
    > On 8/6/18, Paul Crowley <paulcrowley@google.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

    \
     
     \ /
      Last update: 2018-08-07 03:07    [W:5.222 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site