aboutsummaryrefslogtreecommitdiffstats
path: root/include/crypto/internal
Commit message (Collapse)AuthorAge
* crypto: hash - Export shash through hashHerbert Xu2008-12-24
| | | | | | | | 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 <herbert@gondor.apana.org.au>
* crypto: hash - Add import/export interfaceHerbert Xu2008-12-24
| | | | | | | | | | | | 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 means that we only have to compute that base once rather than for each message. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: hash - Add shash interfaceHerbert Xu2008-12-24
| | | | | | | | | | | | | | | | | | | | | | | | 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 other enhancement is that shash no longer takes scatter list entries. This is because shash is specifically designed for synchronous algorithms and as such scatter lists are unnecessary. All existing hash users will be converted to shash once the algorithms have been completely converted. There is also a new finup function that combines update with final. This will be extended to ahash once the algorithm conversion is done. This is also the first time that an algorithm type has their own registration function. Existing algorithm types will be converted to this way in due course. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: rng - RNG interface and implementationNeil Horman2008-08-29
| | | | | | | | | | | | This patch adds a random number generator interface as well as a cryptographic pseudo-random number generator based on AES. It is meant to be used in cases where a deterministic CPRNG is required. One of the first applications will be as an input in the IPsec IV generation process. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: skcipher - Move IV generators into their own modulesHerbert Xu2008-08-29
| | | | | | | | This patch moves the default IV generators into their own modules in order to break a dependency loop between cryptomgr, rng, and blkcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: hash - Move ahash functions into crypto/hash.hHerbert Xu2008-07-10
| | | | | | | | | | | All new crypto interfaces should go into individual files as much as possible in order to ensure that crypto.h does not collapse under its own weight. This patch moves the ahash code into crypto/hash.h and crypto/internal/hash.h respectively. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: hash - Added scatter list walking helperHerbert Xu2008-07-10
| | | | | | | | This patch adds the walking helpers for hash algorithms akin to those of block ciphers. This is a necessary step before we can reimplement existing hash algorithms using the new ahash interface. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Fix section mismatchesHerbert Xu2008-03-08
| | | | | | | | The previous patch to move chainiv and eseqiv into blkcipher created a section mismatch for the chainiv exit function which was also called from __init. This patch removes the __exit marking on it. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Move chainiv/seqiv into crypto_blkcipher moduleHerbert Xu2008-02-22
| | | | | | | | For compatibility with dm-crypt initramfs setups it is useful to merge chainiv/seqiv into the crypto_blkcipher module. Since they're required by most algorithms anyway this is an acceptable trade-off. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] chainiv: Avoid lock spinning where possibleHerbert Xu2008-01-10
| | | | | | | | | | | | | | | | This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] null: Add null blkcipher algorithmHerbert Xu2008-01-10
| | | | | | | | | | This patch adds a null blkcipher algorithm called ecb(cipher_null) for backwards compatibility. Previously the null algorithm when used by IPsec copied the data byte by byte. This new algorithm optimises that to a straight memcpy which lets us better measure inherent overheads in our IPsec code. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] aead: Create default givcipher instancesHerbert Xu2008-01-10
| | | | | | | | | This patch makes crypto_alloc_aead always return algorithms that is capable of generating their own IVs through givencrypt and givdecrypt. All existing AEAD algorithms already do. New ones must either supply their own or specify a generic IV generator with the geniv field. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] aead: Add aead_geniv_alloc/aead_geniv_freeHerbert Xu2008-01-10
| | | | | | | | | This patch creates the infrastructure to help the construction of IV generator templates that wrap around AEAD algorithms by adding an IV generator to them. This is useful for AEAD algorithms with no built-in IV generator or to replace their built-in generator. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Create default givcipher instancesHerbert Xu2008-01-10
| | | | | | | | | | | | | | | This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always return algorithms that are capable of generating their own IVs through givencrypt and givdecrypt. Each algorithm may specify its default IV generator through the geniv field. For algorithms that do not set the geniv field, the blkcipher layer will pick a default. Currently it's chainiv for synchronous algorithms and eseqiv for asynchronous algorithms. Note that if these wrappers do not work on an algorithm then that algorithm must specify its own geniv or it can't be used at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Added skcipher_givcrypt_completeHerbert Xu2008-01-10
| | | | | | | This patch adds the helper skcipher_givcrypt_complete which should be called when an ablkcipher algorithm has completed a givcrypt request. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Add skcipher_geniv_alloc/skcipher_geniv_freeHerbert Xu2008-01-10
| | | | | | | | This patch creates the infrastructure to help the construction of givcipher templates that wrap around existing blkcipher/ablkcipher algorithms by adding an IV generator to them. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Add givcrypt operations and givcipher typeHerbert Xu2008-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Different block cipher modes have different requirements for intialisation vectors. For example, CBC can use a simple randomly generated IV while modes such as CTR must use an IV generation mechanisms that give a stronger guarantee on the lack of collisions. Furthermore, disk encryption modes have their own IV generation algorithms. Up until now IV generation has been left to the users of the symmetric key cipher API. This is inconvenient as the number of block cipher modes increase because the user needs to be aware of which mode is supposed to be paired with which IV generation algorithm. Therefore it makes sense to integrate the IV generation into the crypto API. This patch takes the first step in that direction by creating two new ablkcipher operations, givencrypt and givdecrypt that generates an IV before performing the actual encryption or decryption. The operations are currently not exposed to the user. That will be done once the underlying functionality has actually been implemented. It also creates the underlying givcipher type. Algorithms that directly generate IVs would use it instead of ablkcipher. All other algorithms (including all existing ones) would generate a givcipher algorithm upon registration. This givcipher algorithm will be constructed from the geniv string that's stored in every algorithm. That string will locate a template which is instantiated by the blkcipher/ablkcipher algorithm in question to give a givcipher algorithm. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] skcipher: Add crypto_grab_skcipher interfaceHerbert Xu2008-01-10
Note: From now on the collective of ablkcipher/blkcipher/givcipher will be known as skcipher, i.e., symmetric key cipher. The name blkcipher has always been much of a misnomer since it supports stream ciphers too. This patch adds the function crypto_grab_skcipher as a new way of getting an ablkcipher spawn. The problem is that previously we did this in two steps, first getting the algorithm and then calling crypto_init_spawn. This meant that each spawn user had to be aware of what type and mask to use for these two steps. This is difficult and also presents a problem when the type/mask changes as they're about to be for IV generators. The new interface does both steps together just like crypto_alloc_ablkcipher. As a side-effect this also allows us to be stronger on type enforcement for spawns. For now this is only done for ablkcipher but it's trivial to extend for other types. This patch also moves the type/mask logic for skcipher into the helpers crypto_skcipher_type and crypto_skcipher_mask. Finally this patch introduces the function crypto_require_sync to determine whether the user is specifically requesting a sync algorithm. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>