| 77ec2e734d4820c51cbabe1257e9311df5868160 |
|
11-Jul-2012 |
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> |
crypto: cleanup - remove unneeded crypto_alg.cra_list initializations
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 <jussi.kivilinna@mbnet.fi>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 8d0c123f8b710561cfd34f6e1a5bebc27988edbe |
|
16-Feb-2010 |
Richard Hartmann <richih.mailinglist@gmail.com> |
crypto: aes_generic - Fix checkpatch errors
Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 7b4ffcf953f091a815df081911c5e75c8a38418d |
|
24-Jul-2009 |
Phil Carmody <ext-phil.2.carmody@nokia.com> |
crypto: aes - Undefined behaviour in crypto_aes_expand_key
It's undefined behaviour in C to write outside the bounds of an array.
The key expansion routine takes a shortcut of creating 8 words at a
time, but this creates 4 additional words which don't fit in the array.
As everyone is hopefully now aware, GCC is at liberty to make any
assumptions and optimisations it likes in situations where it can
detect that UB has occured, up to and including nasal demons, and
as the indices being accessed in the array are trivially calculable,
it's rash to invite gcc to do take any liberties at all.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 0ee4a96902dd7858e65f378c86f428a0355bd841 |
|
25-Dec-2008 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: aes - Precompute tables
The tables used by the various AES algorithms are currently
computed at run-time. This has created an init ordering problem
because some AES algorithms may be registered before the tables
have been initialised.
This patch gets around this whole thing by precomputing the tables.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 5427663f498e19b441277de72ce7a685511f247c |
|
01-Apr-2008 |
Sebastian Siewior <sebastian@breakpoint.cc> |
[CRYPTO] aes: Export generic setkey
The key expansion routine could be get little more generic, become
a kernel doc entry and then get exported.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Tested-by: Stefan Hellermann <stefan@the2masters.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 96e82e4551d38e0863b366a7b61185bc4a9946cc |
|
08-Nov-2007 |
Sebastian Siewior <sebastian@breakpoint.cc> |
[CRYPTO] aes-generic: Make key generation exportable
This patch exports four tables and the set_key() routine. This ressources
can be shared by other AES implementations (aes-x86_64 for instance).
The decryption key has been turned around (deckey[0] is the first piece
of the key instead of deckey[keylen+20]). The encrypt/decrypt functions
are looking now identical (except they are using different tables and
key).
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| be5fb270125729b7bca7879967f1dfadff0d9841 |
|
08-Nov-2007 |
Sebastian Siewior <sebastian@breakpoint.cc> |
[CRYPTO] aes-generic: Coding style cleanup
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| 89e12654312dddbbdbf17b5adc95b22cb672f947 |
|
17-Oct-2007 |
Sebastian Siewior <sebastian@breakpoint.cc> |
[CRYPTO] aes: Move common defines into a header file
This three defines are used in all AES related hardware.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| f8246af005d56b73f4f04304fc5b6fd9878af4ef |
|
05-Oct-2007 |
Sebastian Siewior <sebastian@breakpoint.cc> |
[CRYPTO] aes: Rename aes to aes-generic
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.
Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|