Eric Lee / smarc-fsl-linux-kernel

31 May, 2019

1 commit

  • 2874c5fd2   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

20 Nov, 2018

2 commits

  • aa7624093   crypto: chacha - add XChaCha12 support ... Browse Code »

    Now that the generic implementation of ChaCha20 has been refactored to
    allow varying the number of rounds, add support for XChaCha12, which is
    the XSalsa construction applied to ChaCha12. ChaCha12 is one of the
    three ciphers specified by the original ChaCha paper
    (https://cr.yp.to/chacha/chacha-20080128.pdf: "ChaCha, a variant of
    Salsa20"), alongside ChaCha8 and ChaCha20. ChaCha12 is faster than
    ChaCha20 but has a lower, but still large, security margin.

    We need XChaCha12 support so that it can be used in the Adiantum
    encryption mode, which enables disk/file encryption on low-end mobile
    devices where AES-XTS is too slow as the CPUs lack AES instructions.

    We'd prefer XChaCha20 (the more popular variant), but it's too slow on
    some of our target devices, so at least in some cases we do need the
    XChaCha12-based version. In more detail, the problem is that Adiantum
    is still much slower than we're happy with, and encryption still has a
    quite noticeable effect on the feel of low-end devices. Users and
    vendors push back hard against encryption that degrades the user
    experience, which always risks encryption being disabled entirely. So
    we need to choose the fastest option that gives us a solid margin of
    security, and here that's XChaCha12. The best known attack on ChaCha
    breaks only 7 rounds and has 2^235 time complexity, so ChaCha12's
    security margin is still better than AES-256's. Much has been learned
    about cryptanalysis of ARX ciphers since Salsa20 was originally designed
    in 2005, and it now seems we can be comfortable with a smaller number of
    rounds. The eSTREAM project also suggests the 12-round version of
    Salsa20 as providing the best balance among the different variants:
    combining very good performance with a "comfortable margin of security".

    Note that it would be trivial to add vanilla ChaCha12 in addition to
    XChaCha12. However, it's unneeded for now and therefore is omitted.

    As discussed in the patch that introduced XChaCha20 support, I
    considered splitting the code into separate chacha-common, chacha20,
    xchacha20, and xchacha12 modules, so that these algorithms could be
    enabled/disabled independently. However, since nearly all the code is
    shared anyway, I ultimately decided there would have been little benefit
    to the added complexity.

    Reviewed-by: Ard Biesheuvel
    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • 1ca1b9179   crypto: chacha20-generic - refactor to allow varying number of rounds ... Browse Code »

    In preparation for adding XChaCha12 support, rename/refactor
    chacha20-generic to support different numbers of rounds. The
    justification for needing XChaCha12 support is explained in more detail
    in the patch "crypto: chacha - add XChaCha12 support".

    The only difference between ChaCha{8,12,20} are the number of rounds
    itself; all other parts of the algorithm are the same. Therefore,
    remove the "20" from all definitions, structures, functions, files, etc.
    that will be shared by all ChaCha versions.

    Also make ->setkey() store the round count in the chacha_ctx (previously
    chacha20_ctx). The generic code then passes the round count through to
    chacha_block(). There will be a ->setkey() function for each explicitly
    allowed round count; the encrypt/decrypt functions will be the same. I
    decided not to do it the opposite way (same ->setkey() function for all
    round counts, with different encrypt/decrypt functions) because that
    would have required more boilerplate code in architecture-specific
    implementations of ChaCha and XChaCha.

    Reviewed-by: Ard Biesheuvel
    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers