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
     
  • If the user-provided IV needs to be aligned to the algorithm's
    alignmask, then skcipher_walk_virt() copies the IV into a new aligned
    buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then
    if the caller unconditionally accesses walk.iv, it's a use-after-free.

    salsa20-generic doesn't set an alignmask, so currently it isn't affected
    by this despite unconditionally accessing walk.iv. However this is more
    subtle than desired, and it was actually broken prior to the alignmask
    being removed by commit b62b3db76f73 ("crypto: salsa20-generic - cleanup
    and convert to skcipher API").

    Since salsa20-generic does not update the IV and does not need any IV
    alignment, update it to use req->iv instead of walk.iv.

    Fixes: 2407d60872dd ("[CRYPTO] salsa20: Salsa20 stream cipher")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

22 Mar, 2019

1 commit


23 Dec, 2018

1 commit


31 May, 2018

1 commit

  • This reverts commit eb772f37ae8163a89e28a435f6a18742ae06653b, as now the
    x86 Salsa20 implementation has been removed and the generic helpers are
    no longer needed outside of salsa20_generic.c.

    We could keep this just in case someone else wants to add a new
    optimized Salsa20 implementation. But given that we have ChaCha20 now
    too, I think it's unlikely. And this can always be reverted back.

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

    Eric Biggers
     

12 Jan, 2018

2 commits

  • Export the Salsa20 constants, transform context, and initialization
    functions so that they can be reused by the x86 implementation.

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

    Eric Biggers
     
  • Convert salsa20-generic from the deprecated "blkcipher" API to the
    "skcipher" API, in the process fixing it up to be thread-safe (as the
    crypto API expects) by maintaining each request's state separately from
    the transform context.

    Also remove the unnecessary cra_alignmask and tighten validation of the
    key size by accepting only 16 or 32 bytes, not anything in between.

    These changes bring the code close to the way chacha20-generic does
    things, so hopefully it will be easier to maintain in the future.

    However, the way Salsa20 interprets the IV is still slightly different;
    that was not changed.

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

    Eric Biggers
     

29 Nov, 2017

1 commit

  • When asked to encrypt or decrypt 0 bytes, both the generic and x86
    implementations of Salsa20 crash in blkcipher_walk_done(), either when
    doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
    because walk->buffer and walk->page have not been initialized.

    The bug is that Salsa20 is calling blkcipher_walk_done() even when
    nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
    be called when a nonzero number of bytes have been provided.

    The broken code is part of an optimization that tries to make only one
    call to salsa20_encrypt_bytes() to process inputs that are not evenly
    divisible by 64 bytes. To fix the bug, just remove this "optimization"
    and use the blkcipher_walk API the same way all the other users do.

    Reproducer:

    #include
    #include
    #include

    int main()
    {
    int algfd, reqfd;
    struct sockaddr_alg addr = {
    .salg_type = "skcipher",
    .salg_name = "salsa20",
    };
    char key[16] = { 0 };

    algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
    bind(algfd, (void *)&addr, sizeof(addr));
    reqfd = accept(algfd, 0, 0);
    setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
    read(reqfd, key, sizeof(key));
    }

    Reported-by: syzbot
    Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
    Cc: # v2.6.25+
    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


01 Aug, 2012

1 commit

  • Initialization of cra_list is currently mixed, most ciphers initialize this
    field and most shashes do not. Initialization however is not needed at all
    since cra_list is initialized/overwritten in __crypto_register_alg() with
    list_add(). Therefore perform cleanup to remove all unneeded initializations
    of this field in 'crypto/'.

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

    Jussi Kivilinna
     

25 Dec, 2008

1 commit


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

  • This patch fixes the multi-page processing bug that affects large test
    vectors (the same bug that previously affected ctr.c).

    There is an optimization for the case walk.nbytes == nbytes. Also we
    now use crypto_xor() instead of adhoc XOR routines.

    Signed-off-by: Tan Swee Heng
    Signed-off-by: Herbert Xu

    Tan Swee Heng
     
  • This patch implements the Salsa20 stream cipher using the blkcipher interface.

    The core cipher code comes from Daniel Bernstein's submission to eSTREAM:
    http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/salsa20/full/ref/

    The test vectors comes from:
    http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/salsa20/full/

    It has been tested successfully with "modprobe tcrypt mode=34" on an
    UML instance.

    Signed-off-by: Tan Swee Heng
    Signed-off-by: Herbert Xu

    Tan Swee Heng