Re: [PATCH 1/1] CRYPTO: Fix checkpatch errors warnings in cipher.c
On Tue, Feb 16, 2010 at 12:56:15PM +0100, Richard Hartmann wrote:
Thus, I wanted to check if I should wait some more or what the general
consensus of action in the crypto subtree is.
And yes, I am aware that janitor work, and thus my patches, is very low
priority.
For the crypto tree at least I've got all your patches so you
don't have to resend.
For other trees please follow whatever their maintainer (or Greg)
says.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto_remove_spawns: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
On Mon, Feb 15, 2010 at 10:14:08AM +0200, Alexey Dobriyan wrote:
Yes, ipcomp bug triggers almost immediately.
Anyway, this is just description of what I do.
Can you see if this patch makes it go away?
This can happen when you're unloading aes just as an algorithm
that uses aes (such as cbc(aes)) is being created.
diff --git a/crypto/algapi.c b/crypto/algapi.c
index f149b1c..88c5f6c 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -165,6 +165,8 @@ static void crypto_remove_spawns(struct crypto_alg *alg,
spawn-alg = NULL;
spawns = inst-alg.cra_users;
+ if (!spawns-next)
+ break;
}
} while ((spawns = crypto_more_spawns(alg, stack, top,
secondary_spawns)));
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] CRYPTO: Fix checkpatch errors warnings in cipher.c
On Tue, Feb 16, 2010 at 13:00, Herbert Xu herb...@gondor.apana.org.au wrote: For the crypto tree at least I've got all your patches so you don't have to resend. OK, thank you very much. Expect more patches, in this case :) One more question on workflow, though.. I have been checking http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=summary for updates, but obviously, this was the wrong place. Where should I look for your commits so I don't have to have you waste your time answering emails? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] to fix vmac test fails on s390
On Thu, Feb 11, 2010 at 11:18:08AM +0800, Wang, Shane wrote:
static struct hash_testvec aes_vmac128_tv_template[] = {
{
+ .key= \x00\x01\x02\x03\x04\x05\x06\x07
+ \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f,
+ .plaintext = NULL,
+#ifdef __LITTLE_ENDIAN
+ .digest = \x07\x58\x80\x35\x77\xa4\x7b\x54,
+#else
+ .digest = \x54\x7b\xa4\x77\x35\x80\x58\x07,
+#endif
+ .psize = 0,
+ .ksize = 16,
+ }, {
Sorry but you can't fix it like this. Your hash output must be
invariant with respect to endianness.
That means, whether I run it on a big-endian machine or a little-
endian one it should produce the same output.
Otherwise this hash will be totally useless as soon as you get
onto the network.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher
On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
-static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
{
- struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
+ if (unlikely(!ctx-new_key))
+ return;
+ memcpy(iv, ctx-iv, sizeof(ctx-iv));
+ ctx-new_key = 0;
Sorry, but this doesn't work.
A ctx is supposed to be reentrant. That is, while one thread
is working away with a given ctx I should be able to use that
same ctx in a different thread without them clobbering each
other.
So that means (in general) you must not modify the ctx in any
function other than setkey.
This also brings up the bigger question of how we transition to
this new arc4. I don't think we need to maintain exactly the
same behaviour as the existing ecb(arc4).
So what we could do is simply add a new blkcipher arc4, alongside
the existing cipher arc4. Then we can convert the existing users
across, and finally remove the old arc4.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
