25 Dec, 2008
1 commit
-
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
21 Apr, 2008
1 commit
-
The key expansion routine could be get little more generic, become
a kernel doc entry and then get exported.Signed-off-by: Sebastian Siewior
Tested-by: Stefan Hellermann
Signed-off-by: Herbert Xu
11 Jan, 2008
3 commits
-
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
Signed-off-by: Herbert Xu -
Signed-off-by: Sebastian Siewior
Signed-off-by: Herbert Xu -
This three defines are used in all AES related hardware.
Signed-off-by: Sebastian Siewior
Signed-off-by: Herbert Xu
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.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
Signed-off-by: Herbert Xu