aboutsummaryrefslogtreecommitdiff
path: root/crypto/api.c
AgeCommit message (Collapse)Author
2007-02-07[CRYPTO] api: Allow multiple frontends per backendHerbert Xu
This patch adds support for multiple frontend types for each backend algorithm by passing the type and mask through to the backend type init function. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-02-07[CRYPTO] api: Remove deprecated interfaceHerbert Xu
This patch removes the old cipher interface and related code. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] api: Remove unused functionsAdrian Bunk
This patch removes the following no longer used functions: - api.c: crypto_alg_available() - digest.c: crypto_digest_init() - digest.c: crypto_digest_update() - digest.c: crypto_digest_final() - digest.c: crypto_digest_digest() Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-11[CRYPTO] api: fix crypto_alloc_base() return valueAkinobu Mita
This patch makes crypto_alloc_base() return proper return value. - If kzalloc() failure happens within __crypto_alloc_tfm(), crypto_alloc_base() returns NULL. But crypto_alloc_base() is supposed to return error code as pointer. So this patch makes it return -ENOMEM in that case. - crypto_alloc_base() is suppose to return -EINTR, if it is interrupted by signal. But it may not return -EINTR. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Add crypto_comp and crypto_has_*Herbert Xu
This patch adds the crypto_comp type to complete the compile-time checking conversion. The functions crypto_has_alg and crypto_has_cipher, etc. are also added to replace crypto_alg_available. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added crypto_type supportHerbert Xu
This patch adds the crypto_type structure which will be used for all new crypto algorithm types, beginning with block ciphers. The primary purpose of this abstraction is to allow different crypto_type objects for crypto algorithms of the same type, in particular, there will be a different crypto_type objects for asynchronous algorithms. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added crypto_alloc_baseHerbert Xu
Up until now all crypto transforms have been of the same type, struct crypto_tfm, regardless of whether they are ciphers, digests, or other types. As a result of that, we check the types at run-time before each crypto operation. This is rather cumbersome. We could instead use different C types for each crypto type to ensure that the correct types are used at compile time. That is, we would have crypto_cipher/crypto_digest instead of just crypto_tfm. The appropriate type would then be required for the actual operations such as crypto_digest_digest. Now that we have the type/mask fields when looking up algorithms, it is easy to request for an algorithm of the precise type that the user wants. However, crypto_alloc_tfm currently does not expose these new attributes. This patch introduces the function crypto_alloc_base which will carry these new parameters. It will be renamed to crypto_alloc_tfm once all existing users have been converted. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added asynchronous flagHerbert Xu
This patch adds the asynchronous flag and changes all existing users to only look up algorithms that are synchronous. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added spawnsHerbert Xu
Spawns lock a specific crypto algorithm in place. They can then be used with crypto_spawn_tfm to allocate a tfm for that algorithm. When the base algorithm of a spawn is deregistered, all its spawns will be automatically removed. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] api: Allow algorithm lookup by typeHerbert Xu
This patch also adds the infrastructure to pick an algorithm based on their type. For example, this allows you to select the encryption algorithm "aes", instead of any algorithm registered under the name "aes". For now this is only accessible internally. Eventually it will be made available through crypto_alloc_tfm. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] api: Add cryptomgrHerbert Xu
The cryptomgr module is a simple manager of crypto algorithm instances. It ensures that parameterised algorithms of the type tmpl(alg) (e.g., cbc(aes)) are always created. This is meant to satisfy the needs for most users. For more complex cases such as deeper combinations or multiple parameters, a netlink module will be created which allows arbitrary expressions to be parsed in user-space. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] api: Added event notificationHerbert Xu
This patch adds a notifier chain for algorithm/template registration events. This will be used to register compound algorithms such as cbc(aes). In future this will also be passed onto user-space through netlink. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] api: Split out low-level APIHerbert Xu
The crypto API is made up of the part facing users such as IPsec and the low-level part which is used by cryptographic entities such as algorithms. This patch splits out the latter so that the two APIs are more clearly delineated. As a bonus the low-level API can now be modularised if all algorithms are built as modules. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Add crypto_alg reference countingHerbert Xu
Up until now we've relied on module reference counting to ensure that the crypto_alg structures don't disappear from under us. This was good enough as long as each crypto_alg came from exactly one module. However, with parameterised crypto algorithms a crypto_alg object may need two or more modules to operate. This means that we need to count the references to the crypto_alg object directly. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] api: Rename crypto_alg_get to crypto_mod_getHerbert Xu
The functions crypto_alg_get and crypto_alg_put operates on the crypto modules rather than the algorithms. Therefore it makes sense to call them crypto_mod_get and crypto_alg_put respectively. This is needed because we need to have real algorithm reference counters for parameterised algorithms as they can be unregistered from below by when their parameter algorithms are themselves unregistered. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-26[CRYPTO] api: Allow replacement when registering new algorithmsHerbert Xu
We already allow asynchronous removal of existing algorithm modules. By allowing the replacement of existing algorithms, we can replace algorithms without having to wait for for all existing users to complete. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-06-26[CRYPTO] api: Removed const from cra_name/cra_driver_nameHerbert Xu
We do need to change these names now and even more so in future with instantiated algorithms. So let's stop lying to the compiler and get rid of the const modifiers. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-06-26[CRYPTO] api: Added cra_init/cra_exitHerbert Xu
This patch adds the hooks cra_init/cra_exit which are called during a tfm's construction and destruction respectively. This will be used by the instances to allocate child tfm's. For now this lets us get rid of the coa_init/coa_exit functions which are used for exactly that purpose (unlike the dia_init function which is called for each transaction). In fact the coa_exit path is currently buggy as it may get called twice when an error is encountered during initialisation. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-03-21[CRYPTO] all: Use kzalloc where possibleEric Sesterhenn
this patch converts crypto/ to kzalloc usage. Compile tested with allyesconfig. Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-03-21[CRYPTO] api: Align tfm context as wide as possibleHerbert Xu
Since tfm contexts can contain arbitrary types we should provide at least natural alignment (__attribute__ ((__aligned__))) for them. In particular, this is needed on the Xscale which is a 32-bit architecture with a u64 type that requires 64-bit alignment. This problem was reported by Ronen Shitrit. The crypto_tfm structure's size was 44 bytes on 32-bit architectures and 80 bytes on 64-bit architectures. So adding this requirement only means that we have to add an extra 4 bytes on 32-bit architectures. On i386 the natural alignment is 16 bytes which also benefits the VIA Padlock as it no longer has to manually align its context structure to 128 bits. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-01-09[CRYPTO] api: Require block size to be less than PAGE_SIZE/8Herbert Xu
The cipher code path may allocate up to two blocks of data on the stack. Therefore we need to place limits on the maximum block size. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-01-09[CRYPTO] Allow multiple implementations of the same algorithmHerbert Xu
This is the first step on the road towards asynchronous support in the Crypto API. It adds support for having multiple crypto_alg objects for the same algorithm registered in the system. For example, each device driver would register a crypto_alg object for each algorithm that it supports. While at the same time the user may load software implementations of those same algorithms. Users of the Crypto API may then select a specific implementation by name, or choose any implementation for a given algorithm with the highest priority. The priority field is a 32-bit signed integer. In future it will be possible to modify it from user-space. This also provides a solution to the problem of selecting amongst various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-10-30[CRYPTO] Check cra_alignmask against cra_blocksizeHerbert Xu
The cipher code relies on the fact that the block size is a multiple of the required alignment. So we should check this at the time of algorith registration. We also ensure that the block size is bounded by the page size. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-09-01[CRYPTO]: Added CRYPTO_TFM_REQ_MAY_SLEEP flagHerbert Xu
The crypto layer currently uses in_atomic() to determine whether it is allowed to sleep. This is incorrect since spin locks don't always cause in_atomic() to return true. Instead of that, this patch returns to an earlier idea of a per-tfm flag which determines whether sleeping is allowed. Unlike the earlier version, the default is to not allow sleeping. This ensures that no existing code can break. As usual, this flag may either be set through crypto_alloc_tfm(), or just before a specific crypto operation. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-06[CRYPTO] Add null short circuit to crypto_free_tfmJesper Juhl
As far as I'm aware there's a general concensus that functions that are responsible for freeing resources should be able to cope with being passed a NULL pointer. This makes sense as it removes the need for all callers to check for NULL, thus elliminating the bugs that happen when some forget (safer to just check centrally in the freeing function) and it also makes for smaller code all over due to the lack of all those NULL checks. This patch makes it safe to pass the crypto_free_tfm() function a NULL pointer. Once this patch is applied we can start removing the NULL checks from the callers. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-06[CRYPTO] Ensure cit_iv is aligned correctlyHerbert Xu
This patch ensures that cit_iv is aligned according to cra_alignmask by allocating it as part of the tfm structure. As a side effect the crypto layer will also guarantee that the tfm ctx area has enough space to be aligned by cra_alignmask. This allows us to remove the extra space reservation from the Padlock driver. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-06[CRYPTO] Make crypto_alg_lookup staticAdrian Bunk
This patch makes a needlessly global function static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-06[CRYPTO] Add alignmask for low-level cipher implementationsHerbert Xu
The VIA Padlock device requires the input and output buffers to be aligned on 16-byte boundaries. This patch adds the alignmask attribute for low-level cipher implementations to indicate their alignment requirements. The mid-level crypt() function will copy the input/output buffers if they are not aligned correctly before they are passed to the low-level implementation. Strictly speaking, some of the software implementations require the buffers to be aligned on 4-byte boundaries as they do 32-bit loads. However, it is not clear whether it is better to copy the buffers or pay the penalty for unaligned loads/stores. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!