This is the x86-64 version of the Salsa20 stream cipher algorithm. The
original assembly code came from
<http://cr.yp.to/snuffle/salsa20/amd64-3/salsa20.s>. It has been
reformatted for clarity.
Signed-off-by: NTan Swee Heng <thesweeheng@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch contains the salsa20-i586 implementation. The original
assembly code came from
<http://cr.yp.to/snuffle/salsa20/x86-pm/salsa20.s>. I have reformatted
it (added indents) so that it matches the other algorithms in
arch/x86/crypto.
Signed-off-by: NTan Swee Heng <thesweeheng@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch introduces the rfc4106 wrapper for GCM just as we have an
rfc4309 wrapper for CCM.  The purpose of the wrapper is to include part
of the IV in the key so that it can be negotiated by IPsec.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds an async field to /proc/crypto for ablkcipher and aead
algorithms.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch makes chainiv avoid spinning by postponing requests on lock
contention if the user allows the use of asynchronous algorithms.  If
a synchronous algorithm is requested then we behave as before.

This should improve IPsec performance on SMP when two CPUs attempt to
transmit over the same SA.  Currently one of them will spin doing nothing
waiting for the other CPU to finish its encryption.  This patch makes it
postpone the request and get on with other work.

If only one CPU is transmitting for a given SA, then we will process
the request synchronously as before.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that seqiv supports AEAD algorithms it needs to select the AEAD option.

Thanks to Erez Zadok for pointing out the problem.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

It's better to return silently than crash and burn when someone feeds us
a zero length.  In particular the null digest algorithm when used as part
of authenc will do that to us.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We need to allow setkey on digest_null if it is to be used directly by
authenc instead of through hmac.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a null blkcipher algorithm called ecb(cipher_null) for
backwards compatibility.  Previously the null algorithm when used by
IPsec copied the data byte by byte.  This new algorithm optimises that
to a straight memcpy which lets us better measure inherent overheads in
our IPsec code.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds 7 test vectors to tcrypt for CCM.
The test vectors are from rfc 3610.
There are about 10 more test vectors in RFC 3610
and 4 or 5 more in NIST. I can add these as time permits.

I also needed to set authsize. CCM has a prerequisite of
authsize. 
Signed-off-by: NJoy Latten <latten@austin.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds Counter with CBC-MAC (CCM) support.
RFC 3610 and NIST Special Publication 800-38C were referenced.
Signed-off-by: NJoy Latten <latten@austin.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds support for using seqiv with AEAD algorithms.  This is
useful for those AEAD algorithms that performs authentication before
encryption because the IV generated by the underlying encryption algorithm
won't be available for authentication.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

This patch finally makes the givencrypt/givdecrypt operations available
to users by adding crypto_aead_givencrypt and crypto_aead_givdecrypt.
A suite of helpers to allocate and fill in the request is also available.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch implements the givencrypt function for authenc.  It simply
calls the givencrypt operation on the underlying cipher instead of encrypt.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

This patch finally makes the givencrypt/givdecrypt operations available
to users by adding crypto_skcipher_givencrypt and crypto_skcipher_givdecrypt.
A suite of helpers to allocate and fill in the request is also available.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This generator generates an IV based on a sequence number by xoring it
with a salt.  This algorithm is mainly useful for CTR and similar modes.

This patch also sets it as the default IV generator for ctr.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that gcm and authenc have been converted to crypto_spawn_skcipher,
this patch removes the obsolete crypto_spawn_ablkcipher function.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch converts the gcm algorithm over to crypto_grab_skcipher
which is a prerequisite for IV generation.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds the gcm_base template which takes a block cipher
parameter instead of cipher.  This allows the user to specify a
specific CTR implementation.

This also fixes a leak of the cipher algorithm that was previously
looked up but never freed.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch converts the authenc algorithm over to crypto_grab_skcipher
which is a prerequisite for IV generation.

This patch also changes authenc to set its ASYNC status depending on
the ASYNC status of the underlying skcipher.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always
return algorithms that are capable of generating their own IVs through
givencrypt and givdecrypt.  Each algorithm may specify its default IV
generator through the geniv field.

For algorithms that do not set the geniv field, the blkcipher layer will
pick a default.  Currently it's chainiv for synchronous algorithms and
eseqiv for asynchronous algorithms.  Note that if these wrappers do not
work on an algorithm then that algorithm must specify its own geniv or
it can't be used at all.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This generator generates an IV based on a sequence number by xoring it
with a salt and then encrypting it with the same key as used to encrypt
the plain text.  This algorithm requires that the block size be equal
to the IV size.  It is mainly useful for CBC.

It has one noteworthy property that for IPsec the IV happens to lie
just before the plain text so the IV generation simply increases the
number of encrypted blocks by one.  Therefore the cost of this generator
is entirely dependent on the speed of the underlying cipher.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds the helper skcipher_givcrypt_complete which should be
called when an ablkcipher algorithm has completed a givcrypt request.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The chain IV generator is the one we've been using in the IPsec stack.
It simply starts out with a random IV, then uses the last block of each
encrypted packet's cipher text as the IV for the next packet.

It can only be used by synchronous ciphers since we have to make sure
that we don't start the encryption of the next packet until the last
one has completed.

It does have the advantage of using very little CPU time since it doesn't
have to generate anything at all.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch creates the infrastructure to help the construction of givcipher
templates that wrap around existing blkcipher/ablkcipher algorithms by adding
an IV generator to them.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If the underlying algorithm specifies a specific geniv algorithm then
we should use it for the cryptd version as well.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch introduces the geniv field which indicates the default IV
generator for each algorithm.  It should point to a string that is not
freed as long as the algorithm is registered.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Different block cipher modes have different requirements for intialisation
vectors.  For example, CBC can use a simple randomly generated IV while
modes such as CTR must use an IV generation mechanisms that give a stronger
guarantee on the lack of collisions.  Furthermore, disk encryption modes
have their own IV generation algorithms.

Up until now IV generation has been left to the users of the symmetric
key cipher API.  This is inconvenient as the number of block cipher modes
increase because the user needs to be aware of which mode is supposed to
be paired with which IV generation algorithm.

Therefore it makes sense to integrate the IV generation into the crypto
API.  This patch takes the first step in that direction by creating two
new ablkcipher operations, givencrypt and givdecrypt that generates an
IV before performing the actual encryption or decryption.

The operations are currently not exposed to the user.  That will be done
once the underlying functionality has actually been implemented.

It also creates the underlying givcipher type.  Algorithms that directly
generate IVs would use it instead of ablkcipher.  All other algorithms
(including all existing ones) would generate a givcipher algorithm upon
registration.  This givcipher algorithm will be constructed from the geniv
string that's stored in every algorithm.  That string will locate a template
which is instantiated by the blkcipher/ablkcipher algorithm in question to
give a givcipher algorithm.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Note: From now on the collective of ablkcipher/blkcipher/givcipher will
be known as skcipher, i.e., symmetric key cipher.  The name blkcipher has
always been much of a misnomer since it supports stream ciphers too.

This patch adds the function crypto_grab_skcipher as a new way of getting
an ablkcipher spawn.  The problem is that previously we did this in two
steps, first getting the algorithm and then calling crypto_init_spawn.

This meant that each spawn user had to be aware of what type and mask to
use for these two steps.  This is difficult and also presents a problem
when the type/mask changes as they're about to be for IV generators.

The new interface does both steps together just like crypto_alloc_ablkcipher.

As a side-effect this also allows us to be stronger on type enforcement
for spawns.  For now this is only done for ablkcipher but it's trivial
to extend for other types.

This patch also moves the type/mask logic for skcipher into the helpers
crypto_skcipher_type and crypto_skcipher_mask.

Finally this patch introduces the function crypto_require_sync to determine
whether the user is specifically requesting a sync algorithm.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds the necessary changes for GCM to be used with async
ciphers.  This would allow it to be used with hardware devices that
support CTR.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

As discussed previously, this patch moves the basic CTR functionality
into a chainable algorithm called ctr.  The IPsec-specific variant of
it is now placed on top with the name rfc3686.

So ctr(aes) gives a chainable cipher with IV size 16 while the IPsec
variant will be called rfc3686(ctr(aes)).  This patch also adjusts
gcm accordingly.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

With the impending addition of the givcipher type, both blkcipher and
ablkcipher algorithms will use it to create givcipher objects.  As such
it no longer makes sense to split the system between ablkcipher and
blkcipher.  In particular, both ablkcipher.c and blkcipher.c would need
to use the givcipher type which has to reside in ablkcipher.c since it
shares much code with it.

This patch merges the two Kconfig options as well as the modules into one.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fixes the request context alignment so that it is actually
aligned to the value required by the algorithm.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a new helper crypto_attr_alg_name which is basically the
first half of crypto_attr_alg.  That is, it returns an algorithm name
parameter as a string without looking it up.  The caller can then look it
up immediately or defer it until later.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When allocating ablkcipher/hash objects, we use a mask that's wider than
the usual type mask.  This patch sanitises the mask supplied by the user
so we don't end up using a narrower mask which may lead to unintended
results.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

i get here:

----
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  Building modules, stage 2.
  MODPOST 226 modules
ERROR: "crypto_hash_type" [crypto/authenc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
---

which fails because crypto_hash_type is declared in crypto/hash.c. You might wanna
fix it like so:
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>