Module load sequence

Hi, I notice that the crypto in the kernel dynamically loads in crypto modules. It appears that crypto algorithms are loaded first followed by cbc.ko, then crypto_blkcipher.ko and authenc. How does crypto decide which modules to load. It seems related to the string "authenc(hmac(sha1),cbc(aes)

Are there any drivers that use aead.ko

Hi, Are there any example drivers that make use of aead.ko ? Is it true that an AEAD driver can perform encryption and hashing in a single call ? I assume aead.ko is designed for hardware crypto drivers that can do both encryption and hashing concurrently. Am I correct ? Thanks for any info.

libcrc32c: Move implementation to crypto crc32c

Hi: libcrc32c: Move implementation to crypto crc32c This patch swaps the role of libcrc32c and crc32c. Previously the implementation was in libcrc32c and crc32c was a wrapper. Now the code is in crc32c and libcrc32c just calls the crypto layer. The reason for the change is to tap into the algor

Unloading hardware based crypto to fallback to software based crypto

Hi, Is there a mechanism to allow a hardware crypto driver to be unloaded and the IPsec session to fallback to using software based crypto drivers ? The requirement is to not take down the IPsec tunnel whilst unloading the hardware crypto driver. Bascially, the hardware become unavailable durin

What is the difference between aead.ko and authenc.ko ?

Hi, Can anyone explain the difference between aead.ko and authenc.ko ? How does crypto decide to use aead.ko instead of authenc.ko ? I am guessing it is something to do with XFRM ? Thanks, Regards, Dean Jenkins MontaVista Software -- To unsubscribe from this list: send the line "unsubscribe li

[PATCH 10/10] crypto: crc32c - Test descriptor context format

crypto: crc32c - Test descriptor context format This patch adds a test for the requirement that all crc32c algorithms shall store the partial result in the first four bytes of the descriptor context. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/testmgr.c | 51 +

[PATCH 8/10] crypto: crc32c - Switch to shash

crypto: crc32c - Switch to shash This patch changes crc32c to the new shash interface. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/crc32c.c | 185 1 file changed, 53 insertions(+), 132 deletions(-) diff --git a/crypto/crc32

[PATCH 9/10] crypto: crc32c-intel - Switch to shash

crypto: crc32c-intel - Switch to shash This patch changes crc32c-intel to the new shash interface. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- arch/x86/crypto/crc32c-intel.c | 101 +++-- 1 file changed, 47 insertions(+), 54 deletions(-) diff --git a/a

[PATCH 7/10] crypto: hash - Export shash through hash

crypto: hash - Export shash through hash This patch allows shash algorithms to be used through the old hash interface. This is a transitional measure so we can convert the underlying algorithms to shash before converting the users across. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypt

[PATCH 6/10] crypto: api - Call type show function before legacy for proc

crypto: api - Call type show function before legacy for proc This patch makes /proc/crypto call the type-specific show function if one is present before calling the legacy show functions for cipher/digest/compress. This allows us to reuse the type values for those legacy types. In particular, ha

[PATCH 5/10] crypto: hash - Add import/export interface

crypto: hash - Add import/export interface It is often useful to save the partial state of a hash function so that it can be used as a base for two or more computations. The most prominent example is HMAC where all hashes start from a base determined by the key. Having an import/export interface

[PATCH 4/10] crypto: hash - Export shash through ahash

crypto: hash - Export shash through ahash This patch allows shash algorithms to be used through the ahash interface. This is required before we can convert digest algorithms over to shash. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/shash.c | 143 +

[PATCH 3/10] crypto: hash - Add shash interface

crypto: hash - Add shash interface The shash interface replaces the current synchronous hash interface. It improves over hash in two ways. Firstly shash is reentrant, meaning that the same tfm may be used by two threads simultaneously as all hashing state is stored in a local descriptor. The oth

[PATCH 2/10] crypto: api - Rebirth of crypto_alloc_tfm

crypto: api - Rebirth of crypto_alloc_tfm This patch reintroduces a completely revamped crypto_alloc_tfm. The biggest change is that we now take two crypto_type objects when allocating a tfm, a frontend and a backend. In fact this simply formalises what we've been doing behind the API's back. Fo

[PATCH 1/10] crypto: api - Move type exit function into crypto_tfm

crypto: api - Move type exit function into crypto_tfm The type exit function needs to undo any allocations done by the type init function. However, the type init function may differ depending on the upper-level type of the transform (e.g., a crypto_blkcipher instantiated as a crypto_ablkcipher).

[0/10] New crypto hash interface

Hi: The crc32c stuff finally tipped me over the edge into implementing the often-talked about sync hash interface. Our hash interface backend has always been targeted towards software implementations in that it takes byte arrays instead of scatter lists. However, the frontend has always been bas