The setkey() function can be shared with the generic algorithm.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

NO other block mode is M by default.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The setkey() function can be shared with the generic algorithm.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch exports four tables and the set_key() routine. This ressources
can be shared by other AES implementations (aes-x86_64 for instance).
The decryption key has been turned around (deckey[0] is the first piece
of the key instead of deckey[keylen+20]). The encrypt/decrypt functions
are looking now identical (except they are using different tables and
key).
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds countersize to CTR mode.
The template is now ctr(algo,noncesize,ivsize,countersize).

For example, ctr(aes,4,8,4) indicates the counterblock
will be composed of a salt/nonce that is 4 bytes, an iv
that is 8 bytes and the counter is 4 bytes.

When noncesize + ivsize < blocksize, CTR initializes the
last block - ivsize - noncesize portion of the block to
zero.  Otherwise the counter block is composed of the IV
(and nonce if necessary).

If noncesize + ivsize == blocksize, then this indicates that
user is passing in entire counterblock. Thus countersize
indicates the amount of bytes in counterblock to use as
the counter for incrementing. CTR will increment counter
portion by 1, and begin encryption with that value.

Note that CTR assumes the counter portion of the block that
will be incremented is stored in big endian.
Signed-off-by: NJoy Latten <latten@austin.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Move huge unrolled pieces of code (3 screenfuls) at the end of
128/256 key setup routines into common camellia_setup_tail(),
convert it to loop there.
Loop is still unrolled six times, so performance hit is very small,
code size win is big.
Signed-off-by: NDenys Vlasenko <vda.linux@googlemail.com>
Acked-by: NNoriaki TAKAMIYA <takamiya@po.ntts.co.jp>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Optimize GETU32 to use 4-byte memcpy (modern gcc will convert
such memcpy to single move instruction on i386).
Original GETU32 did four byte fetches, and shifted/XORed those.
Signed-off-by: NDenys Vlasenko <vda.linux@googlemail.com>
Acked-by: NNoriaki TAKAMIYA <takamiya@po.ntts.co.jp>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Rename some macros to shorter names: CAMELLIA_RR8 -> ROR8,
making it easier to understand that it is just a right rotation,
nothing camellia-specific in it.
CAMELLIA_SUBKEY_L() -> SUBKEY_L() - just shorter.

Move be32 <-> cpu conversions out of en/decrypt128/256 and into
camellia_en/decrypt - no reason to have that code duplicated twice.
Signed-off-by: NDenys Vlasenko <vda.linux@googlemail.com>
Acked-by: NNoriaki TAKAMIYA <takamiya@po.ntts.co.jp>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Move code blocks around so that related pieces are closer together:
e.g. CAMELLIA_ROUNDSM macro does not need to be separated
from the rest of the code by huge array of constants.

Remove unused macros (COPY4WORD, SWAP4WORD, XOR4WORD[2])

Drop SUBL(), SUBR() macros which only obscure things.
Same for CAMELLIA_SP1110() macro and KEY_TABLE_TYPE typedef.

Remove useless comments:
/* encryption */ -- well it's obvious enough already!
void camellia_encrypt128(...)

Combine swap with copying at the beginning/end of encrypt/decrypt.
Signed-off-by: NDenys Vlasenko <vda.linux@googlemail.com>
Acked-by: NNoriaki TAKAMIYA <takamiya@po.ntts.co.jp>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Currently twofish cipher key setup code
has unrolled loops - approximately 70-100
instructions are repeated 40 times.

As a result, twofish module is the biggest module
in crypto/*.

Unrolling produces x2.5 more code (+18k on i386), and speeds up key
setup by 7%:

	unrolled: twofish_setkey/sec: 41128
	    loop: twofish_setkey/sec: 38148
	CALC_K256: ~100 insns each
	CALC_K192: ~90 insns
	   CALC_K: ~70 insns

Attached patch removes this unrolling.

$ size */twofish_common.o
   text    data     bss     dec     hex filename
  37920       0       0   37920    9420 crypto.org/twofish_common.o
  13209       0       0   13209    3399 crypto/twofish_common.o

Run tested (modprobe tcrypt reports ok). Please apply.
Signed-off-by: NDenys Vlasenko <vda.linux@googlemail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This three defines are used in all AES related hardware.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

HIFN driver update to use DES weak key checks (exported in this patch).
Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch creates include/crypto/des.h for common macros shared between
DES implementations.
Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch implements CTR mode for IPsec.
It is based off of RFC 3686.

Please note:
1. CTR turns a block cipher into a stream cipher.
Encryption is done in blocks, however the last block
may be a partial block.

A "counter block" is encrypted, creating a keystream
that is xor'ed with the plaintext. The counter portion
of the counter block is incremented after each block
of plaintext is encrypted.
Decryption is performed in same manner.

2. The CTR counterblock is composed of,
        nonce + IV + counter

The size of the counterblock is equivalent to the
blocksize of the cipher.
        sizeof(nonce) + sizeof(IV) + sizeof(counter) = blocksize

The CTR template requires the name of the cipher
algorithm, the sizeof the nonce, and the sizeof the iv.
        ctr(cipher,sizeof_nonce,sizeof_iv)

So for example,
        ctr(aes,4,8)
specifies the counterblock will be composed of 4 bytes
from a nonce, 8 bytes from the iv, and 4 bytes for counter
since aes has a blocksize of 16 bytes.

3. The counter portion of the counter block is stored
in big endian for conformance to rfc 3686.
Signed-off-by: NJoy Latten <latten@austin.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

As it is crypto_remove_spawn may try to unregister an instance which is
yet to be registered.  This patch fixes this by checking whether the
instance has been registered before attempting to remove it.

It also removes a bogus cra_destroy check in crypto_register_instance as
1) it's outside the mutex;
2) we have a check in __crypto_register_alg already.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

It seems that newer versions of gcc have regressed in their abilities to
analyse initialisations.  This patch moves the initialisations up to avoid
the warnings.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Not architecture specific code should not #include <asm/scatterlist.h>.

This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

This patch moves the sg_init_table out of the timing loops for hash
algorithms so that it doesn't impact on the speed test results.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use sg_init_one() and sg_init_table() as needed.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

hmac_setkey(), hmac_init(), and hmac_final() have
a singular on-stack scatterlist.  Initialit is
using sg_init_one() instead of using sg_set_buf().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Crypto now uses SG helper functions.  Fix hmac_digest to use those
functions correctly and fix the oops associated with it.
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Most drivers need to set length and offset as well, so may as well fold
those three lines into one.

Add sg_assign_page() for those two locations that only needed to set
the page, where the offset/length is set outside of the function context.
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Convert the subdirectory "crypto" to UTF-8. The files changed are
<crypto/fcrypt.c> and <crypto/api.c>.
Signed-off-by: NJohn Anthony Kazos Jr. <jakj@j-a-k-j.com>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>

It's a subsystem function, prefix it as such.
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

There are currently several SHA implementations that all define their own
initialization vectors and size values. Since this values are idential
move them to a header file under include/crypto.
Signed-off-by: NJan Glauber <jang@de.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.

Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.

Also remove the probe for sha1 in padlock's init code.

Quote from Herbert:
  The probe is actually pointless since we can always probe when
  the algorithm is actually used which does not lead to dead-locks
  like this.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.

Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds the helper blkcipher_walk_virt_block which is similar to
blkcipher_walk_virt but uses a supplied block size instead of the block
size of the block cipher.  This is useful for CTR where the block size is
1 but we still want to walk by the block size of the underlying cipher.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that the block size is no longer a multiple of the alignment, we need to
increase the kmalloc amount in blkcipher_next_slow to use the aligned block
size.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a comment to explain why we compare the cra_driver_name of
the algorithm being registered against the cra_name of a larval as opposed
to the cra_driver_name of the larval.

In fact larvals have only one name, cra_name which is the name that was
requested by the user.  The test here is simply trying to find out whether
the algorithm being registered can or can not satisfy the larval.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Previously we assumed for convenience that the block size is a multiple of
the algorithm's required alignment.  With the pending addition of CTR this
will no longer be the case as the block size will be 1 due to it being a
stream cipher.  However, the alignment requirement will be that of the
underlying implementation which will most likely be greater than 1.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We do not allow spaces in algorithm names or parameters.  Thanks to Joy Latten
for pointing this out.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

As Joy Latten points out, inner algorithm parameters will miss the closing
bracket which will also cause the outer algorithm to terminate prematurely.

This patch fixes that also kills the WARN_ON if the number of parameters
exceed the maximum as that is a user error.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

XTS currently considered to be the successor of the LRW mode by the IEEE1619
workgroup. LRW was discarded, because it was not secure if the encyption key
itself is encrypted with LRW.

XTS does not have this problem. The implementation is pretty straightforward,
a new function was added to gf128mul to handle GF(128) elements in ble format.
Four testvectors from the specification
	http://grouper.ieee.org/groups/1619/email/pdf00086.pdf
were added, and they verify on my system.
Signed-off-by: NRik Snel <rsnel@cube.dyndns.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use max in blkcipher_get_spot() instead of open coding it.
Signed-off-by: NIngo Oeser <ioe-lkml@rameria.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When scatterwalk is built as a module digest.c was broken because it
requires the crypto_km_types structure which is in scatterwalk.  This
patch removes the crypto_km_types structure by encoding the logic into
crypto_kmap_type directly.

In fact, this even saves a few bytes of code (not to mention the data
structure itself) on i386 which is about the only place where it's
needed.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds the authenc algorithm which constructs an AEAD algorithm
from an asynchronous block cipher and a hash.  The construction is done
by concatenating the encrypted result from the cipher with the output
from the hash, as is used by the IPsec ESP protocol.

The authenc algorithm exists as a template with four parameters:

	authenc(auth, authsize, enc, enckeylen).

The authentication algorithm, the authentication size (i.e., truncating
the output of the authentication algorithm), the encryption algorithm,
and the encryption key length.  Both the size field and the key length
field are in bytes.  For example, AES-128 with SHA1-HMAC would be
represented by

	authenc(hmac(sha1), 12, cbc(aes), 16)

The key for the authenc algorithm is the concatenation of the keys for
the authentication algorithm with the encryption algorithm.  For the
above example, if a key of length 36 bytes is given, then hmac(sha1)
would receive the first 20 bytes while the last 16 would be given to
cbc(aes).
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>