summaryrefslogtreecommitdiff
path: root/crypto/aead.c
AgeCommit message (Collapse)AuthorFilesLines
2009-02-18crypto: aead - Avoid infinite loop when nivaead fails selftestHerbert Xu1-0/+16
When an aead constructed through crypto_nivaead_default fails its selftest, we'll loop forever trying to construct new aead objects but failing because it already exists. The crux of the issue is that once an aead fails the selftest, we'll ignore it on the next run through crypto_aead_lookup and attempt to construct a new aead. We should instead return an error to the caller if we find an an that has failed the test. This bug hasn't manifested itself yet because we don't have any test vectors for the existing nivaead algorithms. They're tested through the underlying algorithms only. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] api: Show async typeHerbert Xu1-0/+4
This patch adds an async field to /proc/crypto for ablkcipher and aead algorithms. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] aead: Create default givcipher instancesHerbert Xu1-0/+153
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>
2008-01-11[CRYPTO] aead: Add aead_geniv_alloc/aead_geniv_freeHerbert Xu1-5/+211
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>
2008-01-11[CRYPTO] aead: Allow algorithms with no givcrypt supportHerbert Xu1-3/+3
Some algorithms always require manual IV construction. For instance, the generic CCM algorithm requires the first byte of the IV to be manually constructed. Such algorithms are always used by other algorithms equipped with their own IV generators and do not need IV generation per se. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] aead: Add givcrypt operationsHerbert Xu1-0/+7
This patch adds the underlying givcrypt operations for aead and associated support elements. The rationale is identical to that of the skcipher givcrypt operations, i.e., sometimes only the algorithm knows how the IV should be generated. A new request type aead_givcrypt_request is added which contains an embedded aead_request structure with two new elements to support this operation. The new elements are seq and giv. The seq field should contain a strictly increasing 64-bit integer which may be used by certain IV generators as an input value. The giv field will be used to store the generated IV. It does not need to obey the alignment requirements of the algorithm because it's not used during the operation. The existing iv field must still be available as it will be used to store intermediate IVs and the output IV if chaining is desired. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] aead: Make authsize a run-time parameterHerbert Xu1-3/+21
As it is authsize is an algorithm paramter which cannot be changed at run-time. This is inconvenient because hardware that implements such algorithms would have to register each authsize that they support separately. Since authsize is a property common to all AEAD algorithms, we can add a function setauthsize that sets it at run-time, just like setkey. This patch does exactly that and also changes authenc so that authsize is no longer a parameter of its template. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-11[CRYPTO] api: Add aead crypto typeHerbert Xu1-0/+101
This patch adds crypto_aead which is the interface for AEAD (Authenticated Encryption with Associated Data) algorithms. AEAD algorithms perform authentication and encryption in one step. Traditionally users (such as IPsec) would use two different crypto algorithms to perform these. With AEAD this comes down to one algorithm and one operation. Of course if traditional algorithms were used we'd still be doing two operations underneath. However, real AEAD algorithms may allow the underlying operations to be optimised as well. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>