On Mon, Apr 27, 2009 at 04:56:20PM +0800, Herbert Xu wrote:
On Fri, Apr 24, 2009 at 12:27:20PM +0200, Steffen Klassert wrote:
+ alg = crypto_get_attr_alg(tb, algt-type,
+ (algt-mask CRYPTO_ALG_TYPE_MASK)
+ | CRYPTO_ALG_PCRYPT);
On Tue, Apr 28, 2009 at 08:23:16AM +0200, Steffen Klassert wrote:
I don't need to exclude it. I just wanted to avoid another layer
of pcrypt here because it does not make too much sense to parallelize
a second time. If the aead algorithm is already parallel it would just
add overhead if we
On Tue, Apr 28, 2009 at 02:31:29PM +0800, Herbert Xu wrote:
I thought so. The system is certainly not going to automatically
construct a second pcrypt algorithm once one exists. So I think
we can just remove this bit.
Ok, so I will remove it in the next version.
Steffen
--
To
On Mon, Apr 27, 2009 at 04:53:46PM +0800, Herbert Xu wrote:
While this should work for pcrypt, I'd like this to be solved
more generally. The crux of the issue is that we can't specify
an arbitrary implementation of a given algorithm. So the obvious
solution is to specify the driver name
I think this might have already been posted by Neil Horman, and
we already have it in the Red Hat Enterprise Linux 5.x kernels,
but in fips mode, we need to panic on the base cipher self-tests
failing as well as the later tests.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
crypto/testmgr.c
Per the NIST AESAVS document, Appendix A[1], it isn't possible to
have automated self-tests for counter-mode AES, but people are
misled to believe something is wrong by the message that says there
is no test for ctr(aes). Simply suppress all 'no test for ctr(aes*'
messages if fips_enabled is set
