delta/linux.git/include/linux/crypto.h, branch proc-cmdline

crypto: doc - Document remaining members in struct crypto_alg

2018-03-23T15:48:43+00:00

Add missing comments for union members ablkcipher, blkcipher,
cipher, and compress. This silences complaints when building
the htmldocs.

Fixes: 0d7f488f0305a (crypto: doc - cipher data structures)
Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu

crypto: hash - prevent using keyed hashes without setting key

2018-01-12T12:03:37+00:00

Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding.  Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated using
"hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
via a (potentially exploitable) stack buffer overflow.

A while ago, this problem was solved for AF_ALG by pairing each hash
transform with a 'has_key' bool.  However, there are still other places
in the kernel where userspace can specify an arbitrary hash algorithm by
name, and the kernel uses it as unkeyed hash without checking whether it
is really unkeyed.  Examples of this include:

    - KEYCTL_DH_COMPUTE, via the KDF extension
    - dm-verity
    - dm-crypt, via the ESSIV support
    - dm-integrity, via the "internal hash" mode with no key given
    - drbd (Distributed Replicated Block Device)

This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
privileges to call.

Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
->crt_flags of each hash transform that indicates whether the transform
still needs to be keyed or not.  Then, make the hash init, import, and
digest functions return -ENOKEY if the key is still needed.

The new flag also replaces the 'has_key' bool which algif_hash was
previously using, thereby simplifying the algif_hash implementation.

Reported-by: syzbot 
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: hash - annotate algorithms taking optional key

2018-01-12T12:03:35+00:00

We need to consistently enforce that keyed hashes cannot be used without
setting the key.  To do this we need a reliable way to determine whether
a given hash algorithm is keyed or not.  AF_ALG currently does this by
checking for the presence of a ->setkey() method.  However, this is
actually slightly broken because the CRC-32 algorithms implement
->setkey() but can also be used without a key.  (The CRC-32 "key" is not
actually a cryptographic key but rather represents the initial state.
If not overridden, then a default initial state is used.)

Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
indicates that the algorithm has a ->setkey() method, but it is not
required to be called.  Then set it on all the CRC-32 algorithms.

The same also applies to the Adler-32 implementation in Lustre.

Also, the cryptd and mcryptd templates have to pass through the flag
from their underlying algorithm.

Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: algapi - convert cra_refcnt to refcount_t

2018-01-05T07:43:09+00:00

Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs.  crypto_alg.cra_refcount is a
reference counter with the usual semantics, so switch it over to
refcount_t.

Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: introduce crypto wait for async op

2017-11-03T14:11:18+00:00

Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.

This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.

Signed-off-by: Gilad Ben-Yossef 
CC: Eric Biggers 
CC: Jonathan Cameron 
Signed-off-by: Herbert Xu

crypto: api - Extend algorithm name limit to 128 bytes

2017-04-10T11:17:27+00:00

With the new explicit IV generators, we may now exceed the 64-byte
length limit on the algorithm name, e.g., with

	echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))

This patch extends the length limit to 128 bytes.

Reported-by: Alexander Sverdlin 
Signed-off-by: Herbert Xu 
Acked-by: Alexander Sverdlin 
Tested-by: Alexander Sverdlin

Merge tag 'docs-4.10-2' of git://git.lwn.net/linux

2016-12-18T00:00:34+00:00

Pull more documentation updates from Jonathan Corbet:
 "This converts the crypto DocBook to Sphinx"

* tag 'docs-4.10-2' of git://git.lwn.net/linux:
  crypto: doc - optimize compilation
  crypto: doc - clarify AEAD memory structure
  crypto: doc - remove crypto_alloc_ablkcipher
  crypto: doc - add KPP documentation
  crypto: doc - fix separation of cipher / req API
  crypto: doc - fix source comments for Sphinx
  crypto: doc - remove crypto API DocBook
  crypto: doc - convert crypto API documentation to Sphinx

crypto: doc - fix source comments for Sphinx

2016-12-13T23:38:05+00:00

Update comments to avoid any complaints from Sphinx during compilation.

Signed-off-by: Stephan Mueller 
Signed-off-by: Jonathan Corbet

crypto: api - fix comment typo

2016-12-01T13:06:30+00:00

Signed-off-by: Baruch Siach 
Signed-off-by: Herbert Xu

crypto: acomp - add driver-side scomp interface

2016-10-25T03:08:31+00:00

Add a synchronous back-end (scomp) to acomp. This allows to easily
expose the already present compression algorithms in LKCF via acomp.

Signed-off-by: Giovanni Cabiddu 
Signed-off-by: Herbert Xu