kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-28 19:20:30 +00:00
Code Issues Releases Packages Activity
linux/crypto/aes_generic.c

1477 lines
62 KiB
Raw Permalink Normal View History

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>
2010-02-16 20:34:59 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-10-17 23:18:57 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
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>
2008-12-25 11:05:13 +11:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
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>
2008-12-25 11:05:13 +11:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
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>
2010-02-16 20:34:59 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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>
2009-07-24 13:59:17 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
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>
2009-07-24 13:59:17 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30 21:25:15 +11:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
[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>
2007-11-08 21:20:30 +08:00
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>
2009-07-24 13:59:17 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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>
2009-07-24 13:59:17 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2008-04-01 20:58:51 +08:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2006-05-16 22:09:29 +10:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] Use standard byte order macros wherever possible A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30 21:25:15 +11:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30 21:25:15 +11:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2006-05-16 22:09:29 +10:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] Use standard byte order macros wherever possible A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30 21:25:15 +11:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30 21:25:15 +11:00
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!
2005-04-16 15:20:36 -07:00
[CRYPTO] Allow AES C/ASM implementations to coexist As the Crypto API now allows multiple implementations to be registered for the same algorithm, we no longer have to play tricks with Kconfig to select the right AES implementation. This patch sets the driver name and priority for all the AES implementations and removes the Kconfig conditions on the C implementation for AES. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-11-05 18:06:26 +11:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] cipher: Set alignmask for multi-byte loads Many cipher implementations use 4-byte/8-byte loads/stores which require alignment on some architectures. This patch explicitly sets the alignment requirements for them. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-01-07 16:38:15 +11:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
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!
2005-04-16 15:20:36 -07:00
[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>
2007-10-05 16:52:01 +08:00