summaryrefslogtreecommitdiffstats
path: root/crypto/algif_rng.c
AgeCommit message (Collapse)AuthorFilesLines
2015-04-22crypto: algif_rng - Remove obsolete const-removal castHerbert Xu1-1/+1
Now that crypto_rng_reset takes a const argument, we no longer need to cast away the const qualifier. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds1-1/+1
Pull crypto update from Herbert Xu: "Here is the crypto update for 4.1: New interfaces: - user-space interface for AEAD - user-space interface for RNG (i.e., pseudo RNG) New hashes: - ARMv8 SHA1/256 - ARMv8 AES - ARMv8 GHASH - ARM assembler and NEON SHA256 - MIPS OCTEON SHA1/256/512 - MIPS img-hash SHA1/256 and MD5 - Power 8 VMX AES/CBC/CTR/GHASH - PPC assembler AES, SHA1/256 and MD5 - Broadcom IPROC RNG driver Cleanups/fixes: - prevent internal helper algos from being exposed to user-space - merge common code from assembly/C SHA implementations - misc fixes" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (169 commits) crypto: arm - workaround for building with old binutils crypto: arm/sha256 - avoid sha256 code on ARMv7-M crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer crypto: x86/sha256_ssse3 - move SHA-224/256 SSSE3 implementation to base layer crypto: x86/sha1_ssse3 - move SHA-1 SSSE3 implementation to base layer crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer crypto: arm/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer crypto: arm/sha256 - move SHA-224/256 ASM/NEON implementation to base layer crypto: arm/sha1-ce - move SHA-1 ARMv8 implementation to base layer crypto: arm/sha1_neon - move SHA-1 NEON implementation to base layer crypto: arm/sha1 - move SHA-1 ARM asm implementation to base layer crypto: sha512-generic - move to generic glue implementation crypto: sha256-generic - move to generic glue implementation crypto: sha1-generic - move to generic glue implementation crypto: sha512 - implement base layer for SHA-512 crypto: sha256 - implement base layer for SHA-256 crypto: sha1 - implement base layer for SHA-1 crypto: api - remove instance when test failed crypto: api - Move alg ref count init to crypto_check_alg ...
2015-03-16crypto: algif_rng - zeroize buffer with random dataStephan Mueller1-1/+1
Due to the change to RNGs to always return zero in success case, the RNG interface must zeroize the buffer with the length provided by the caller. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-03-02net: Remove iocb argument from sendmsg and recvmsgYing Xue1-2/+2
After TIPC doesn't depend on iocb argument in its internal implementations of sendmsg() and recvmsg() hooks defined in proto structure, no any user is using iocb argument in them at all now. Then we can drop the redundant iocb argument completely from kinds of implementations of both sendmsg() and recvmsg() in the entire networking stack. Cc: Christoph Hellwig <hch@lst.de> Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14crypto: algif_rng - fix sparse non static symbol warningWei Yongjun1-1/+1
Fixes the following sparse warnings: crypto/algif_rng.c:185:13: warning: symbol 'rng_exit' was not declared. Should it be static? Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by: Stephan Mueller <smueller@chronox.de> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-12-29crypto: algif_rng - add random number generator supportStephan Mueller1-0/+192
This patch adds the random number generator support for AF_ALG. A random number generator's purpose is to generate data without requiring the caller to provide any data. Therefore, the AF_ALG interface handler for RNGs only implements a callback handler for recvmsg. The following parameters provided with a recvmsg are processed by the RNG callback handler: * sock - to resolve the RNG context data structure accessing the RNG instance private to the socket * len - this parameter allows userspace callers to specify how many random bytes the RNG shall produce and return. As the kernel context for the RNG allocates a buffer of 128 bytes to store random numbers before copying them to userspace, the len parameter is checked that it is not larger than 128. If a caller wants more random numbers, a new request for recvmsg shall be made. The size of 128 bytes is chose because of the following considerations: * to increase the memory footprint of the kernel too much (note, that would be 128 bytes per open socket) * 128 is divisible by any typical cryptographic block size an RNG may have * A request for random numbers typically only shall supply small amount of data like for keys or IVs that should only require one invocation of the recvmsg function. Note, during instantiation of the RNG, the code checks whether the RNG implementation requires seeding. If so, the RNG is seeded with output from get_random_bytes. A fully working example using all aspects of the RNG interface is provided at http://www.chronox.de/libkcapi.html Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>