11 Sep, 2020

1 commit

  • Cryptographic algorithms may have a lifespan that is significantly
    shorter than Linux's, and so we need to start phasing out algorithms
    that are known to be broken, and are no longer fit for general use.

    RC4 (or arc4) is a good example here: there are a few areas where its
    use is still somewhat acceptable, e.g., for interoperability with legacy
    wifi hardware that can only use WEP or TKIP data encryption, but that
    should not imply that, for instance, use of RC4 based EAP-TLS by the WPA
    supplicant for negotiating TKIP keys is equally acceptable, or that RC4
    should remain available as a general purpose cryptographic transform for
    all in-kernel and user space clients.

    Now that all in-kernel users that need to retain support have moved to
    the arc4 library interface, and the known users of ecb(arc4) via the
    socket API (iwd [0] and libell [1][2]) have been updated to switch to a
    local implementation, we can take the next step, and mark the ecb(arc4)
    skcipher as obsolete, and only provide it if the socket API is enabled in
    the first place, as well as provide the option to disable all algorithms
    that have been marked as obsolete.

    [0] https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=1db8a85a60c64523
    [1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
    [2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

09 Jul, 2019

1 commit

  • Pull crypto updates from Herbert Xu:
    "Here is the crypto update for 5.3:

    API:
    - Test shash interface directly in testmgr
    - cra_driver_name is now mandatory

    Algorithms:
    - Replace arc4 crypto_cipher with library helper
    - Implement 5 way interleave for ECB, CBC and CTR on arm64
    - Add xxhash
    - Add continuous self-test on noise source to drbg
    - Update jitter RNG

    Drivers:
    - Add support for SHA204A random number generator
    - Add support for 7211 in iproc-rng200
    - Fix fuzz test failures in inside-secure
    - Fix fuzz test failures in talitos
    - Fix fuzz test failures in qat"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
    crypto: stm32/hash - remove interruptible condition for dma
    crypto: stm32/hash - Fix hmac issue more than 256 bytes
    crypto: stm32/crc32 - rename driver file
    crypto: amcc - remove memset after dma_alloc_coherent
    crypto: ccp - Switch to SPDX license identifiers
    crypto: ccp - Validate the the error value used to index error messages
    crypto: doc - Fix formatting of new crypto engine content
    crypto: doc - Add parameter documentation
    crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
    crypto: arm64/aes-ce - add 5 way interleave routines
    crypto: talitos - drop icv_ool
    crypto: talitos - fix hash on SEC1.
    crypto: talitos - move struct talitos_edesc into talitos.h
    lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
    crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
    crypto: asymmetric_keys - select CRYPTO_HASH where needed
    crypto: serpent - mark __serpent_setkey_sbox noinline
    crypto: testmgr - dynamically allocate crypto_shash
    crypto: testmgr - dynamically allocate testvec_config
    crypto: talitos - eliminate unneeded 'done' functions at build time
    ...

    Linus Torvalds
     

20 Jun, 2019

2 commits

  • There are no remaining users of the cipher implementation, and there
    are no meaningful ways in which the arc4 cipher can be combined with
    templates other than ECB (and the way we do provide that combination
    is highly dubious to begin with).

    So let's drop the arc4 cipher altogether, and only keep the ecb(arc4)
    skcipher, which is used in various places in the kernel.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • Refactor the core rc4 handling so we can move most users to a library
    interface, permitting us to drop the cipher interface entirely in a
    future patch. This is part of an effort to simplify the crypto API
    and improve its robustness against incorrect use.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

13 Jun, 2019

1 commit

  • Most generic crypto algorithms declare a driver name ending in
    "-generic". The rest don't declare a driver name and instead rely on
    the crypto API automagically appending "-generic" upon registration.

    Having multiple conventions is unnecessarily confusing and makes it
    harder to grep for all generic algorithms in the kernel source tree.
    But also, allowing NULL driver names is problematic because sometimes
    people fail to set it, e.g. the case fixed by commit 417980364300
    ("crypto: cavium/zip - fix collision with generic cra_driver_name").

    Of course, people can also incorrectly name their drivers "-generic".
    But that's much easier to notice / grep for.

    Therefore, let's make cra_driver_name mandatory. In preparation for
    this, this patch makes all generic algorithms set cra_driver_name.

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

    Eric Biggers
     

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
     

15 Feb, 2019

1 commit

  • Some arc4 cipher algorithm defines show up in two places:
    crypto/arc4.c and drivers/crypto/bcm/cipher.h.
    Let's export them in a common header and update their users.

    Signed-off-by: Iuliana Prodan
    Reviewed-by: Horia Geantă
    Signed-off-by: Herbert Xu

    Iuliana Prodan
     

11 Jan, 2019

1 commit

  • Convert the "ecb(arc4)" algorithm from the deprecated "blkcipher" API to
    the "skcipher" API.

    (Note that this is really a stream cipher and not a block cipher in ECB
    mode as the name implies, but that's a problem for another day...)

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

    Eric Biggers
     

24 Nov, 2014

1 commit


14 Jun, 2012

2 commits

  • This patch changes u8 in struct arc4_ctx and variables to u32 (as AMD seems
    to have problem with u8 array). Below are tcrypt results of old 1-byte block
    cipher versus ecb(arc4) with u8 and ecb(arc4) with u32.

    tcrypt results, x86-64 (speed ratios: new-u32/old, new-u8/old):

    u32 u8
    AMD Phenom II : x3.6 x2.7
    Intel Core 2 : x2.0 x1.9

    tcrypt results, i386 (speed ratios: new-u32/old, new-u8/old):

    u32 u8
    Intel Atom N260 : x1.5 x1.4

    Cc: Jon Oberheide
    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     
  • Currently arc4.c provides simple one-byte blocksize cipher which is wrapped
    by ecb() module, giving function call overhead on every encrypted byte. This
    patch adds ecb(arc4) directly into arc4.c for higher performance.

    tcrypt results (speed ratios: new/old):

    AMD Phenom II, x86-64 : x2.7
    Intel Core 2, x86-64 : x1.9
    Intel Atom N260, i386 : x1.4

    Cc: Jon Oberheide
    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

30 Jun, 2011

1 commit


21 Sep, 2006

1 commit

  • Now that the tfm is passed directly to setkey instead of the ctx, we no
    longer need to pass the &tfm->crt_flags pointer.

    This patch also gets rid of a few unnecessary checks on the key length
    for ciphers as the cipher layer guarantees that the key length is within
    the bounds specified by the algorithm.

    Rather than testing dia_setkey every time, this patch does it only once
    during crypto_alloc_tfm. The redundant check from crypto_digest_setkey
    is also removed.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

26 Jun, 2006

1 commit

  • Up until now algorithms have been happy to get a context pointer since
    they know everything that's in the tfm already (e.g., alignment, block
    size).

    However, once we have parameterised algorithms, such information will
    be specific to each tfm. So the algorithm API needs to be changed to
    pass the tfm structure instead of the context pointer.

    This patch is basically a text substitution. The only tricky bit is
    the assembly routines that need to get the context pointer offset
    through asm-offsets.h.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds