#
47309ea1 |
|
27-Nov-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: arc4 - Add internal state The arc4 algorithm has always had internal state. It's been buggy from day one in that the state has been stored in the shared tfm object. That means two users sharing the same tfm will end up affecting each other's output, or worse, they may end up with the same output. Fix this by declaring an internal state and storing the state there instead of within the tfm context. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
0ae4dcc1 |
|
27-Nov-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: skcipher - Add internal state support Unlike chaining modes such as CBC, stream ciphers other than CTR usually hold an internal state that must be preserved if the operation is to be done piecemeal. This has not been represented in the API, resulting in the inability to split up stream cipher operations. This patch adds the basic representation of an internal state to skcipher and lskcipher. In the interest of backwards compatibility, the default has been set such that existing users are assumed to be operating in one go as opposed to piecemeal. With the new API, each lskcipher/skcipher algorithm has a new attribute called statesize. For skcipher, this is the size of the buffer that can be exported or imported similar to ahash. For lskcipher, instead of providing a buffer of ivsize, the user now has to provide a buffer of ivsize + statesize. Each skcipher operation is assumed to be final as they are now, but this may be overridden with a request flag. When the override occurs, the user may then export the partial state and reimport it later. For lskcipher operations this is reversed. All operations are not final and the state will be exported unless the FINAL bit is set. However, the CONT bit still has to be set for the state to be used. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
9a91792d |
|
02-Oct-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: arc4 - Convert from skcipher to lskcipher Replace skcipher implementation with lskcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
9ace6771 |
|
31-Aug-2020 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: arc4 - mark ecb(arc4) skcipher as obsolete 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 <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
611a23c2 |
|
12-Jun-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: arc4 - remove cipher implementation 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 <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
dc51f257 |
|
12-Jun-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: arc4 - refactor arc4 core code into separate library 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 <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
d6ebf528 |
|
02-Jun-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: make all generic algorithms set cra_driver_name 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 <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
2874c5fd |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 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 <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c4741b23 |
|
11-Apr-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: run initcalls for generic implementations earlier 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 <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
bd30cf53 |
|
08-Feb-2019 |
Iuliana Prodan <iuliana.prodan@nxp.com> |
crypto: export arc4 defines 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 <iuliana.prodan@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
426bcb50 |
|
03-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: arc4 - convert to skcipher API 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 <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
5d26a105 |
|
20-Nov-2014 |
Kees Cook <keescook@chromium.org> |
crypto: prefix module autoloading with "crypto-" This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
d366db60 |
|
09-Jun-2012 |
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> |
crypto: arc4 - improve performance by using u32 for ctx and variables 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 <jon@oberheide.org> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
ce6dd368 |
|
09-Jun-2012 |
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> |
crypto: arc4 - improve performance by adding ecb(arc4) 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 <jon@oberheide.org> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
cfa2b54e |
|
08-Jun-2011 |
Mati Vait <mativait@gmail.com> |
crypto: arc4 - Fixed coding style issues Fixed coding style issues: unnecessary spaces, parentheses on wrong lines. Signed-off-by: Mati Vait <mativait@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
560c06ae |
|
12-Aug-2006 |
Herbert Xu <herbert@gondor.apana.org.au> |
[CRYPTO] api: Get rid of flags argument to setkey 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@gondor.apana.org.au>
|
#
6c2bb98b |
|
16-May-2006 |
Herbert Xu <herbert@gondor.apana.org.au> |
[CRYPTO] all: Pass tfm instead of ctx to algorithms 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@gondor.apana.org.au>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 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!
|