The RNG may not be available during early boot, e.g., the relevant
modules may not be included in the initramfs.  As the RNG Is only
needed for IPsec, we should not let this prevent use of ciphers
without IV generators, e.g., for disk encryption.

This patch postpones the RNG allocation to the init function so
that one failure during early boot does not make the RNG unavailable
for all subsequent users of the same cipher.

More importantly, it lets the cipher live even if RNG allocation
fails.  Of course we no longer offer IV generation and which will
fail with an error if invoked.  But all other cipher capabilities
will function as usual.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We currently do the IV seeding on the first givencrypt call in
order to conserve entropy.  However, this does not work with
DRBG which cannot be called from interrupt context.  In fact,
with DRBG we don't need to conserve entropy anyway.  So this
patch moves the seeding into the init function.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This adds the module loading prefix "crypto-" to the template lookup
as well.

For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":

	net-pf-38
	algif-hash
	crypto-vfat(blowfish)
	crypto-vfat(blowfish)-all
	crypto-vfat
Reported-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Change formal parameters to not clash with global names to
eliminate many W=2 warnings.
Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use scatterwalk_crypto_chain in favor of locally defined chaining functions.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If crypto_ablkcipher_encrypt() returns synchronous,
eseqiv_complete2() is called even if req->giv is already the
pointer to the generated IV. The generated IV is overwritten
with some random data in this case. This patch fixes this by
calling eseqiv_complete2() just if the generated IV has to be
copied to req->giv.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch makes the IV generators use the new RNG interface so
that the user can pick an RNG other than the default get_random_bytes.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch moves the default IV generators into their own modules
in order to break a dependency loop between cryptomgr, rng, and
blkcipher.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

After attaching the IV to the head during encryption, eseqiv does not
increase the encryption length by that amount.  As such the last block
of the actual plain text will be left unencrypted.

Fortunately the only user of this code hifn currently crashes so this
shouldn't affect anyone :)
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The previous patch to move chainiv and eseqiv into blkcipher created
a section mismatch for the chainiv exit function which was also called
from __init.  This patch removes the __exit marking on it.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

For compatibility with dm-crypt initramfs setups it is useful to merge
chainiv/seqiv into the crypto_blkcipher module.  Since they're required
by most algorithms anyway this is an acceptable trade-off.
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>