31 May, 2019

1 commit

  • 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
     

18 Apr, 2019

1 commit

  • Use subsys_initcall for registration of all templates and generic
    algorithm implementations, rather than module_init. Then change
    cryptomgr to use arch_initcall, to place it before the subsys_initcalls.

    This is needed so that when both a generic and optimized implementation
    of an algorithm are built into the kernel (not loadable modules), the
    generic implementation is registered before the optimized one.
    Otherwise, the self-tests for the optimized implementation are unable to
    allocate the generic implementation for the new comparison fuzz tests.

    Note that on arm, a side effect of this change is that self-tests for
    generic implementations may run before the unaligned access handler has
    been installed. So, unaligned accesses will crash the kernel. This is
    arguably a good thing as it makes it easier to detect that type of bug.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

28 Sep, 2018

1 commit

  • In the quest to remove all stack VLA usage from the kernel[1], this
    replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage
    with struct crypto_sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK(),
    which uses a fixed stack size.

    [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com

    Signed-off-by: Kees Cook
    Signed-off-by: Herbert Xu

    Kees Cook
     

22 Dec, 2017

1 commit


13 Sep, 2016

1 commit

  • The current implementation uses a global per-cpu array to store
    data which are used to derive the next IV. This is insecure as
    the attacker may change the stored data.

    This patch removes all traces of chaining and replaces it with
    multiplication of the salt and the sequence number.

    Fixes: a10f554fa7e0 ("crypto: echainiv - Add encrypted chain IV...")
    Cc: stable@vger.kernel.org
    Reported-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Herbert Xu
     

18 Jul, 2016

1 commit


17 Aug, 2015

2 commits


14 Jul, 2015

1 commit

  • This patch fixes a bug where we were incorrectly including the
    IV in the AD during encryption. The IV must remain in the plain
    text for it to be encrypted.

    During decryption there is no need to copy the IV to dst because
    it's now part of the AD.

    This patch removes an unncessary check on authsize which would be
    performed by the underlying decrypt call.

    Finally this patch makes use of the type-safe init/exit functions.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

22 Jun, 2015

1 commit


04 Jun, 2015

1 commit

  • We currently do the IV seeding on the first givencrypt call in
    order to conserve entropy. However, this does not work with
    DRBG which cannot be called from interrupt context. In fact,
    with DRBG we don't need to conserve entropy anyway. So this
    patch moves the seeding into the init function.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

28 May, 2015

3 commits


25 May, 2015

4 commits


22 May, 2015

1 commit

  • This patch adds a new AEAD IV generator echainiv. It is intended
    to replace the existing skcipher IV generator eseqiv.

    If the underlying AEAD algorithm is using the old AEAD interface,
    then echainiv will simply use its IV generator.

    Otherwise, echainiv will encrypt a counter just like eseqiv but
    it'll first xor it against a previously stored IV similar to
    chainiv.

    Signed-off-by: Herbert Xu

    Herbert Xu