21 Sep, 2006
36 commits
-
This patch converts all users to use the new crypto_comp type and the
crypto_has_* functions.Signed-off-by: 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
-
This patch removes the old HMAC implementation now that nobody uses it
anymore.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
-
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
-
This patch converts tcrypt to use the new block cipher type where
applicable.Signed-off-by: Herbert Xu
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
This patch adds the asynchronous flag and changes all existing users to
only look up algorithms that are synchronous.Signed-off-by: Herbert Xu
-
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
-
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
-
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
-
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
-
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
-
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
-
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
Signed-off-by: Herbert 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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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
-
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
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller -
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% CyclesTwofish Assembler vs. AES Assembler (128bit 8kb block CBC)
encrypt: +18% Cycles
decrypt: +15% CyclesTwofish Assembler vs. AES Assembler (256bit 8kb block CBC)
encrypt: -9% Cycles
decrypt: -8% CyclesFull 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.txtHere 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
Signed-off-by: Herbert Xu -
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% CyclesTwofish Assembler vs. AES Assembler (128bit 8kb block CBC)
encrypt: +3% Cycles
decrypt: -22% CyclesTwofish Assembler vs. AES Assembler (256bit 8kb block CBC)
encrypt: -20% Cycles
decrypt: -36% CyclesFull 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.txtHere 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
Signed-off-by: Herbert Xu -
This patch adds a proper driver name and priority to the generic c
implemtation to allow coexistance of c and assembler modules.Signed-off-by: Joachim Fritschi
Signed-off-by: Herbert Xu -
This patch splits up the twofish crypto routine into a common part ( key
setup ) which will be uses by all twofish crypto modules ( generic-c , i586
assembler and x86_64 assembler ) and generic-c part. It also creates a new
header file which will be used by all 3 modules.This eliminates all code duplication.
Correctness was verified with the tcrypt module and automated test scripts.
Signed-off-by: Joachim Fritschi
Signed-off-by: Herbert Xu
26 Jun, 2006
4 commits
-
It makes no sense to build tcrypt into the kernel. In fact, now that
the driver init function's return status is being checked, it is in
fact harmful to do so.Signed-off-by: Herbert Xu
-
This patch adds speed tests (benchmarks) for digest algorithms.
Tests are run with different buffer sizes (16 bytes, ... 8 kBytes)
and with each buffer multiple tests are run with different update()
sizes (e.g. hash 64 bytes buffer in four 16 byte updates).
There is no correctness checking of the result and all tests and
algorithms use the same input buffer.Signed-off-by: Michal Ludvig
Signed-off-by: Herbert Xu -
Intentionaly return -EAGAIN from module_init() to ensure
it doesn't stay loaded in the kernel. The module does all
its work from init() and doesn't offer any runtime
functionality => we don't need it in the memory, do we?Signed-off-by: Michal Ludvig
Signed-off-by: Herbert 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