summaryrefslogtreecommitdiffstats
path: root/crypto
AgeCommit message (Collapse)AuthorFilesLines
2006-12-13[PATCH] uml problems with linux/io.hAl Viro1-1/+0
Remove useless includes of linux/io.h, don't even try to build iomap_copy on uml (it doesn't have readb() et.al., so...) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-11[CRYPTO] sha512: Fix sha384 block sizeHerbert Xu1-1/+1
The SHA384 block size should be 128 bytes, not 96 bytes. This was spotted by Andrew Donofrio. Fortunately the block size isn't actually used anywhere so this typo has had no real impact. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] lrw: round --> lrw_roundDavid S. Miller1-2/+2
Fixes: crypto/lrw.c:99: warning: conflicting types for built-in function ‘round’ Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-06[CRYPTO] tcrypt: LRW test vectorsRik Snel2-4/+542
Do modprobe tcrypt mode=10 to check the included test vectors, they are from: http://grouper.ieee.org/groups/1619/email/pdf00017.pdf and from http://www.mail-archive.com/stds-p1619@listserv.ieee.org/msg00173.html. To make the last test vector fit, I had to increase the buffer size of input and result to 512 bytes. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow block cipher modeRik Snel3-0/+315
Main module, this implements the Liskov Rivest Wagner block cipher mode in the new blockcipher API. The implementation is based on ecb.c. The LRW-32-AES specification I used can be found at: http://grouper.ieee.org/groups/1619/email/pdf00017.pdf It implements the optimization specified as optional in the specification, and in addition it uses optimized multiplication routines from gf128mul.c. Since gf128mul.[ch] is not tested on bigendian, this cipher mode may currently fail badly on bigendian machines. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] lib: table driven multiplications in GF(2^128)Rik Snel3-0/+477
A lot of cypher modes need multiplications in GF(2^128). LRW, ABL, GCM... I use functions from this library in my LRW implementation and I will also use them in my ABL (Arbitrary Block Length, an unencumbered (correct me if I am wrong, wide block cipher mode). Elements of GF(2^128) must be presented as u128 *, it encourages automatic and proper alignment. The library contains support for two different representations of GF(2^128), see the comment in gf128mul.h. There different levels of optimization (memory/speed tradeoff). The code is based on work by Dr Brian Gladman. Notable changes: - deletion of two optimization modes - change from u32 to u64 for faster handling on 64bit machines - support for 'bbe' representation in addition to the, already implemented, 'lle' representation. - move 'inline void' functions from header to 'static void' in the source file - update to use the linux coding style conventions The original can be found at: http://fp.gladman.plus.com/AES/modes.vc8.19-06-06.zip The copyright (and GPL statement) of the original author is preserved. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] api: Remove unused functionsAdrian Bunk2-63/+0
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-12-06[CRYPTO] xcbc: Make needlessly global code staticAdrian Bunk1-6/+8
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote: >... > Changes since 2.6.19-rc5-mm2: >... > git-cryptodev.patch >... > git trees >... This patch makes some needlessly global code static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] tcrypt: Add test vectors of AES_XCBCKazunori MIYAZAWA2-0/+71
est vectors of XCBC with AES-128. Signed-off-by: Kazunori MIYAZAWA <miyazawa@linux-ipv6.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-12-06[CRYPTO] xcbc: New algorithmKazunori MIYAZAWA3-0/+358
This is core code of XCBC. XCBC is an algorithm that forms a MAC algorithm out of a cipher algorithm. For example, AES-XCBC-MAC is a MAC algorithm based on the AES cipher algorithm. Signed-off-by: Kazunori MIYAZAWA <miyazawa@linux-ipv6.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-11-22WorkStruct: Pass the work_struct pointer instead of context dataDavid Howells1-3/+4
Pass the work_struct pointer to the work function rather than context data. The work function can use container_of() to work out the data. For the cases where the container of the work_struct may go away the moment the pending bit is cleared, it is made possible to defer the release of the structure by deferring the clearing of the pending bit. To make this work, an extra flag is introduced into the management side of the work_struct. This governs auto-release of the structure upon execution. Ordinarily, the work queue executor would release the work_struct for further scheduling or deallocation by clearing the pending bit prior to jumping to the work function. This means that, unless the driver makes some guarantee itself that the work_struct won't go away, the work function may not access anything else in the work_struct or its container lest they be deallocated.. This is a problem if the auxiliary data is taken away (as done by the last patch). However, if the pending bit is *not* cleared before jumping to the work function, then the work function *may* access the work_struct and its container with no problems. But then the work function must itself release the work_struct by calling work_release(). In most cases, automatic release is fine, so this is the default. Special initiators exist for the non-auto-release case (ending in _NAR). Signed-Off-By: David Howells <dhowells@redhat.com>
2006-10-16[CRYPTO] api: Select cryptomgr where neededHerbert Xu1-1/+3
Since cryptomgr is the only way to construct algorithm instances for now it makes sense to let the templates depend on it as otherwise it may be left off inadvertently. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-11[CRYPTO] api: fix crypto_alloc_base() return valueAkinobu Mita1-7/+8
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-10-10[PATCH] serpent: fix endian warningsAlexey Dobriyan1-8/+8
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-23[CRYPTO] hmac: Fix error truncation by unlikely()Herbert Xu1-6/+18
The error return values are truncated by unlikely so we need to save it first. Thanks to Kyle Moffett for spotting this. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-23[CRYPTO] hmac: Fix hmac_init update callHerbert Xu1-1/+1
The crypto_hash_update call in hmac_init gave the number 1 instead of the length of the sg list in bytes. This is a missed conversion from the digest => hash change. As tcrypt only tests crypto_hash_digest it didn't catch this. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-21[CRYPTO] users: Use crypto_comp and crypto_has_*Herbert Xu1-4/+4
This patch converts all users to use the new crypto_comp type and the crypto_has_* functions. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Add crypto_comp and crypto_has_*Herbert Xu1-0/+14
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] digest: Remove old HMAC implementationHerbert Xu4-117/+2
This patch removes the old HMAC implementation now that nobody uses it anymore. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] tcrypt: Use HMAC template and hash interfaceHerbert Xu2-165/+213
This patch converts tcrypt to use the new HMAC template rather than the hard-coded version of HMAC. It also converts all digest users to use the new cipher interface. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] hmac: Add crypto template implementationHerbert Xu2-6/+236
This patch rewrites HMAC as a crypto template. This means that HMAC is no longer a hard-coded part of the API. It's now a template that generates standard digest algorithms like any other. The old HMAC is preserved until all current users are converted. The same structure can be used by other MACs such as AES-XCBC-MAC. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[CRYPTO] digest: Added user API for new hash typeHerbert Xu6-36/+177
The existing digest user interface is inadequate for support asynchronous operations. For one it doesn't return a value to indicate success or failure, nor does it take a per-operation descriptor which is essential for the issuing of requests while other requests are still outstanding. This patch is the first in a series of steps to remodel the interface for asynchronous operations. For the ease of transition the new interface will be known as "hash" while the old one will remain as "digest". This patch also changes sg_next to allow chaining. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Mark parts of cipher interface as deprecatedHerbert Xu1-6/+28
Mark the parts of the cipher interface that have been replaced by block ciphers as deprecated. Thanks to Andrew Morton for suggesting doing this before removing them completely. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] tcrypt: Use block ciphers where applicableHerbert Xu1-176/+259
This patch converts tcrypt to use the new block cipher type where applicable. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] s390: Added block cipher versions of CBC/ECBHerbert Xu1-0/+2
This patch adds block cipher algorithms for S390. Once all users of the old cipher type have been converted the existing CBC/ECB non-block cipher operations will be removed. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] cipher: Added block ciphers for CBC/ECBHerbert Xu5-1/+544
This patch adds two block cipher algorithms, CBC and ECB. These are implemented as templates on top of existing single-block cipher algorithms. They invoke the single-block cipher through the new encrypt_one/decrypt_one interface. This also optimises the in-place encryption and decryption to remove the cost of an IV copy each round. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] cipher: Added block cipher typeHerbert Xu3-0/+411
This patch adds the new type of block ciphers. Unlike current cipher algorithms which operate on a single block at a time, block ciphers operate on an arbitrarily long linear area of data. As it is block-based, it will skip any data remaining at the end which cannot form a block. The block cipher has one major difference when compared to the existing block cipher implementation. The sg walking is now performed by the algorithm rather than the cipher mid-layer. This is needed for drivers that directly support sg lists. It also improves performance for all algorithms as it reduces the total number of indirect calls by one. In future the existing cipher algorithm will be converted to only have a single-block interface. This will be done after all existing users have switched over to the new block cipher type. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] scatterwalk: Prepare for block ciphersHerbert Xu3-82/+82
This patch prepares the scatterwalk code for use by the new block cipher type. Firstly it halves the size of scatter_walk on 32-bit platforms. This is important as we allocate at least two of these objects on the stack for each block cipher operation. It also exports the symbols since the block cipher code can be built as a module. Finally there is a hack in scatterwalk_unmap that relies on progress being made. Unfortunately, for hardware crypto we can't guarantee progress to be made since the hardware can fail. So this also gets rid of the hack by not advancing the address returned by scatterwalk_map. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] cipher: Added encrypt_one/decrypt_oneHerbert Xu1-0/+48
This patch adds two new operations for the simple cipher that encrypts or decrypts a single block at a time. This will be the main interface after the existing block operations have moved over to the new block ciphers. It also adds the crypto_cipher type which is currently only used on the new operations but will be extended to setkey as well once existing users have been converted to use block ciphers where applicable. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added crypto_type supportHerbert Xu2-10/+27
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: Feed flag directly to crypto_yieldHerbert Xu3-4/+4
The sleeping flag used to determine whether crypto_yield can actually yield is really a per-operation flag rather than a per-tfm flag. This patch changes crypto_yield to take a flag directly so that we can start using a per-operation flag instead the tfm flag. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added crypto_alloc_baseHerbert Xu1-0/+60
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 Xu1-2/+3
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: Add common instance initialisation codeHerbert Xu1-0/+53
This patch adds the helpers crypto_get_attr_alg and crypto_alloc_instance which can be used by simple one-argument templates like hmac to process input parameters and allocate instances. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] cipher: Removed special IV checks for ECBHerbert Xu1-0/+2
This patch makes IV operations on ECB fail through nocrypt_iv rather than calling BUG(). This is needed to generalise CBC/ECB using the template mechanism. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] tcrypt: Use test_hash for crc32cHerbert Xu2-105/+180
Now that crc32c has been fixed to conform with standard digest semantics, we can use test_hash for it. I've turned the last test into a chunky test. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] digest: Store temporary digest in tfmHerbert Xu2-7/+18
When the final result location is unaligned, we store the digest in a temporary buffer before copying it to the final location. Currently that buffer sits on the stack. This patch moves it to an area in the tfm, just like the CBC IV buffer. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Get rid of flags argument to setkeyHerbert Xu17-75/+42
Now that the tfm is passed directly to setkey instead of the ctx, we no longer need to pass the &tfm->crt_flags pointer. This patch also gets rid of a few unnecessary checks on the key length for ciphers as the cipher layer guarantees that the key length is within the bounds specified by the algorithm. Rather than testing dia_setkey every time, this patch does it only once during crypto_alloc_tfm. The redundant check from crypto_digest_setkey is also removed. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] crc32c: Fix unconventional setkey usageHerbert Xu2-10/+19
The convention for setkey is that once it is set it should not change, in particular, init must not wipe out the key set by it. In fact, init should always be used after setkey before any digestion is performed. The only user of crc32c that sets the key is tcrypt. This patch adds the necessary init calls there. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] sha: Add module aliases for sha1 / sha256Michal Ludvig2-0/+6
Crypto modules should be loadable by their .cra_driver_name, so we should make MODULE_ALIAS()es with these names. This patch adds aliases for SHA1 and SHA256 only as that's what we need for PadLock-SHA driver. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] api: Added spawnsHerbert Xu4-53/+265
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 Xu4-18/+40
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 Xu4-1/+164
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 Xu3-13/+196
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: Add template registrationHerbert Xu2-22/+151
A crypto_template generates a crypto_alg object when given a set of parameters. this patch adds the basic data structure fo templates and code to handle their registration/deregistration. 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 Xu6-133/+184
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 Xu2-6/+29
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 Xu1-7/+7
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-09-21[CRYPTO] twofish: x86-64 assembly versionJoachim Fritschi1-0/+15
The patch passed the trycpt tests and automated filesystem tests. This rewrite resulted in some nice perfomance increase over my last patch. Short summary of the tcrypt benchmarks: Twofish Assembler vs. Twofish C (256bit 8kb block CBC) encrypt: -27% Cycles decrypt: -23% Cycles Twofish Assembler vs. AES Assembler (128bit 8kb block CBC) encrypt: +18% Cycles decrypt: +15% Cycles Twofish Assembler vs. AES Assembler (256bit 8kb block CBC) encrypt: -9% Cycles decrypt: -8% Cycles Full Output: http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-c-x86_64.txt http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-asm-x86_64.txt http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-aes-asm-x86_64.txt Here is another bonnie++ benchmark with encrypted filesystems. Most runs maxed out the hd. It should give some idea what the module can do for encrypted filesystem performance even though you can't see the full numbers. http://homepages.tu-darmstadt.de/~fritschi/twofish/output_20060610_130806_x86_64.html Signed-off-by: Joachim Fritschi <jfritschi@freenet.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] twofish: i586 assembly versionJoachim Fritschi1-0/+15
The patch passed the trycpt tests and automated filesystem tests. This rewrite resulted in some nice perfomance increase over my last patch. Short summary of the tcrypt benchmarks: Twofish Assembler vs. Twofish C (256bit 8kb block CBC) encrypt: -33% Cycles decrypt: -45% Cycles Twofish Assembler vs. AES Assembler (128bit 8kb block CBC) encrypt: +3% Cycles decrypt: -22% Cycles Twofish Assembler vs. AES Assembler (256bit 8kb block CBC) encrypt: -20% Cycles decrypt: -36% Cycles Full Output: http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-asm-i586.txt http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-c-i586.txt http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-aes-asm-i586.txt Here is another bonnie++ benchmark with encrypted filesystems. All runs with the twofish assembler modules max out the drivespeed. It should give some idea what the module can do for encrypted filesystem performance even though you can't see the full numbers. http://homepages.tu-darmstadt.de/~fritschi/twofish/output_20060611_205432_x86.html Signed-off-by: Joachim Fritschi <jfritschi@freenet.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>