09 Jan, 2020

1 commit

  • The CRYPTO_TFM_RES_WEAK_KEY flag was apparently meant as a way to make
    the ->setkey() functions provide more information about errors.

    However, no one actually checks for this flag, which makes it pointless.
    There are also no tests that verify that all algorithms actually set (or
    don't set) it correctly.

    This is also the last remaining CRYPTO_TFM_RES_* flag, which means that
    it's the only thing still needing all the boilerplate code which
    propagates these flags around from child => parent tfms.

    And if someone ever needs to distinguish this error in the future (which
    is somewhat unlikely, as it's been unneeded for a long time), it would
    be much better to just define a new return value like -EKEYREJECTED.
    That would be much simpler, less error-prone, and easier to test.

    So just remove this flag.

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

    Eric Biggers
     

22 Aug, 2019

4 commits

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

    Ard Biesheuvel
     
  • Another one for the cipher museum: split off DES core processing into
    a separate module so other drivers (mostly for crypto accelerators)
    can reuse the code without pulling in the generic DES cipher itself.
    This will also permit the cipher interface to be made private to the
    crypto API itself once we move the only user in the kernel (CIFS) to
    this library interface.

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

    Ard Biesheuvel
     
  • In preparation of moving the shared key expansion routine into the
    DES library, move the verification done by __des3_ede_setkey() into
    its callers.

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

    Ard Biesheuvel
     
  • The recently added helper routine to perform key strength validation
    of triple DES keys is slightly inadequate, since it comes in two versions,
    neither of which are highly useful for anything other than skciphers (and
    many drivers still use the older blkcipher interfaces).

    So let's add a new helper and, considering that this is a helper function
    that is only intended to be used by crypto code itself, put it in a new
    des.h header under crypto/internal.

    While at it, implement a similar helper for single DES, so that we can
    start replacing the pattern of calling des_ekey() into a temp buffer
    that occurs in many drivers in drivers/crypto.

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

    Ard Biesheuvel
     

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

2 commits

  • 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
     
  • This patch adds a requirement to the generic 3DES implementation
    such that 2-key 3DES (K1 == K3) is no longer allowed in FIPS mode.

    We will also provide helpers that may be used by drivers that
    implement 3DES to make the same check.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Jan, 2019

1 commit

  • CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it
    sounds like it is requesting a weak key. Actually, it is requesting
    that weak keys be forbidden (for algorithms that have the notion of
    "weak keys"; currently only DES and XTS do).

    Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which
    it can be easily confused. (This in fact happened in the UX500 driver,
    though just in some debugging messages.)

    Therefore, make the intent clear by renaming it to
    CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.

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

    Eric Biggers
     

13 Jan, 2015

1 commit

  • Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    changed the automatic module loading when requesting crypto algorithms
    to prefix all module requests with "crypto-". This requires all crypto
    modules to have a crypto specific module alias even if their file name
    would otherwise match the requested crypto algorithm.

    Even though commit 5d26a105b5a7 added those aliases for a vast amount of
    modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
    annotations to those files to make them get loaded automatically, again.
    This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
    with kernels v3.18 and below.

    Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
    won't work for crypto modules any more.

    Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook
    Signed-off-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Mathias Krause
     

24 Nov, 2014

1 commit


20 Jun, 2014

1 commit

  • Patch adds x86_64 assembly implementation of Triple DES EDE cipher algorithm.
    Two assembly implementations are provided. First is regular 'one-block at
    time' encrypt/decrypt function. Second is 'three-blocks at time' function that
    gains performance increase on out-of-order CPUs.

    tcrypt test results:

    Intel Core i5-4570:

    des3_ede-asm vs des3_ede-generic:
    size ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
    16B 1.21x 1.22x 1.27x 1.36x 1.25x 1.25x
    64B 1.98x 1.96x 1.23x 2.04x 2.01x 2.00x
    256B 2.34x 2.37x 1.21x 2.40x 2.38x 2.39x
    1024B 2.50x 2.47x 1.22x 2.51x 2.52x 2.51x
    8192B 2.51x 2.53x 1.21x 2.56x 2.54x 2.55x

    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

01 Aug, 2012

1 commit


07 Oct, 2010

1 commit


16 Feb, 2010

1 commit


25 Dec, 2008

1 commit

  • While its a slightly insane to bypass the key1 == key2 ||
    key2 == key3 check in triple-des, since it reduces it to the
    same strength as des, some folks do need to do this from time
    to time for backwards compatibility with des.

    My own case is FIPS CAVS test vectors. Many triple-des test
    vectors use a single key, replicated 3x. In order to get the
    expected results, des3_ede_setkey() needs to only reject weak
    keys if the CRYPTO_TFM_REQ_WEAK_KEY flag is set.

    Also sets a more appropriate RES flag when a weak key is found.

    Signed-off-by: Jarod Wilson
    Signed-off-by: Herbert Xu

    Jarod Wilson
     

21 Apr, 2008

1 commit

  • On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
    > Kamalesh Babulal wrote:
    >
    > > This patch cleanups the crypto code, replaces the init() and fini()
    > > with the _init/_fini
    >
    > This part ist OK.
    >
    > > or init/fini_ (if the
    > > _init/_fini exist)
    >
    > Having init_foo and foo_init won't be a good thing, will it? I'd start
    > confusing them.
    >
    > What about foo_modinit instead?

    Thanks for the suggestion, the init() is replaced with

    _mod_init ()

    and fini () is replaced with _mod_fini.

    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Herbert Xu

    Kamalesh Babulal
     

11 Jan, 2008

2 commits


11 Oct, 2007

1 commit

  • Loading the crypto algorithm by the alias instead of by module directly
    has the advantage that all possible implementations of this algorithm
    are loaded automatically and the crypto API can choose the best one
    depending on its priority.

    Signed-off-by: Sebastian Siewior
    Signed-off-by: Herbert Xu

    Sebastian Siewior