Re: [camellia-oss:00952] Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization

[Noriaki TAKAMIYA]

Hi,

  sorry, again.

>> Tue, 13 Nov 2007 15:07:02 +0900 (JST) 
>> [Subject: [camellia-oss:00952] Re: [PATCH 5/5] camellia: de-unrolling, 
>> 64bit-ization] 
>> Noriaki TAKAMIYA <[EMAIL PROTECTED]> wrote...

> > I'd like to hear the opinion of the author.
> > 
> > Takamiya-san, what do you think about this change?
> 
>   For IPsec processing, I think performance is important.
> 
>   If this fix improves the performance, it is acceptable.

  I misunderstood the meaning. If this fix decreases the performance,
  I wouldn't prefer this patch(and the below is also one of the
  reason).

>   But, there are many duplicate decralations between camellia.c and
>   camellia_64.c...
>   (e.g., CAMELLIA_MIN_KEY_SIZE and so on)

  Regards,

--
Noriaki TAKAMIYA
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization

[Noriaki TAKAMIYA]

Hi,

  Sorry for late reply

>> Thu, 8 Nov 2007 21:30:20 +0800 頃、
>> [Subject: Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization] において、
>> Herbert Xu <[EMAIL PROTECTED]>さんが書きました

> On Wed, Nov 07, 2007 at 01:22:52PM +, Denys Vlasenko wrote:
> >
> > *I* am happy with 5% speed sacrifice. I'm afraid other people won't be.
> 
> I'd like to hear the opinion of the author.
> 
> Takamiya-san, what do you think about this change?

  For IPsec processing, I think performance is important.

  If this fix improves the performance, it is acceptable.

  But, there are many duplicate decralations between camellia.c and
  camellia_64.c...
  (e.g., CAMELLIA_MIN_KEY_SIZE and so on)

  Regards,

--
Noriaki TAKAMIYA
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] [eSTREAM] stream: Wrapper for eSTREAM ciphers

[Herbert Xu]

Tan Swee Heng <[EMAIL PROTECTED]> wrote:
> This patch implements a template that wraps around an eSTREAM cipher
> algorithm and its ivsize.

Why couldn't straem ciphers that require an IV just use the
blkcipher interface? Please enlighten me :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New Crypto Hardware

[Herbert Xu]

Loc Ho <[EMAIL PROTECTED]> wrote:
> 
> What is the current state of asynchronous hashing? Will AEAD be changed to

It's on my todo list but it's not the highest priority.

> make use of asynchronous hashing? Is anyone working on #1 and changing AEAD

You mean authenc? AEAD is just an interface which doesn't use
hashing directly.   If you mean the authenc algorithm which combines
encryption and hashing then yes it will be changed.  That would
be a fairly straightforward change too.

> to asychronous interface? In addition, most of the existent device driver

I'm not aware of any ongoing work so any contributions in this
area would definitely be welcome.

> only use  synchronous interface. Are there any one changing them to
> asynchronous crypto interface - such as NETKEY (Linux IPSec)?

That I am working on right now :) See the recent 24 patche set
I posted to netdev.  What's missing now is just the change to
get ESP to actually use AEAD.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] stream: Stream cipher wrapper

[Herbert Xu]

On Tue, Nov 13, 2007 at 03:44:42AM +0800, Tan Swee Heng wrote:
>
> I agree that Salsa20 can be implemented this way as it is essentially
> a hash function in counter mode. However this is not true in general
> of other eSTREAM candidates. I am hoping to find a general solution
> for eSTREAM ciphers, not just Salsa20.

Well we already support at least one stream cipher, arc4 with
the cipher interface.

For stream ciphers that have IVs, they can just use the blkcipher
interface.  Is there anything else that's required?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] [eSTREAM] stream: Wrapper for eSTREAM ciphers

[Tan Swee Heng]

Sorry I omitted the patch. Here it is.

On Nov 13, 2007 3:59 AM, Tan Swee Heng <[EMAIL PROTECTED]> wrote:
> This patch implements a template that wraps around an eSTREAM cipher
> algorithm and its ivsize.
>
> For example, an eSTREAM cipher with the name CIPHERNAME and ivsize
> IVSIZE will be instantiated as "stream(CIPHERNAME,IVSIZE)" in
> cryptomgr. It uses blkcipher to walk over the memory it
> encrypts/decrypts. It has been modified to use the crypto_estream_*
> type instead of crypto_cipher_*.
>
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4ad25fd..27a802f 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -211,6 +211,16 @@ config CRYPTO_CTR
  CTR: Counter mode
  This block cipher algorithm is required for IPSec.
 
+config CRYPTO_STREAM
+   tristate "STREAM: Wrapper for eSTREAM ciphers (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_MANAGER
+   select CRYPTO_ESTREAM
+   help
+ STREAM: Wrapper for eSTREAM ciphers
+ This wrapper is used by stream ciphers submitted to eSTREAM.
+
 config CRYPTO_CRYPTD
tristate "Software async crypto daemon"
select CRYPTO_ABLKCIPHER
diff --git a/crypto/Makefile b/crypto/Makefile
index 14afa34..f95206b 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_CRYPTO_PCBC) += pcbc.o
 obj-$(CONFIG_CRYPTO_LRW) += lrw.o
 obj-$(CONFIG_CRYPTO_XTS) += xts.o
 obj-$(CONFIG_CRYPTO_CTR) += ctr.o
+obj-$(CONFIG_CRYPTO_STREAM) += stream.o
 obj-$(CONFIG_CRYPTO_CRYPTD) += cryptd.o
 obj-$(CONFIG_CRYPTO_DES) += des_generic.o
 obj-$(CONFIG_CRYPTO_FCRYPT) += fcrypt.o
diff --git a/crypto/stream.c b/crypto/stream.c
new file mode 100644
index 000..0c2ffc7
--- /dev/null
+++ b/crypto/stream.c
@@ -0,0 +1,241 @@
+/*
+ * STREAM: Wrapper for eSTREAM ciphers
+ *
+ * Copyright (c) 2007 Tan Swee Heng <[EMAIL PROTECTED]>
+ *
+ * Derived from
+ * - cbc.c: Copyright (c) 2006 Herbert Xu <[EMAIL PROTECTED]>
+ * - ctr.c: Copyright (c) IBM Corp. 2007 Joy Latten <[EMAIL PROTECTED]>
+ *
+ * Stream ciphers submitted to eSTREAM, the ECRYPT Stream Cipher Project,
+ * requires both key size and IV size in the key setup. This is different
+ * from standard block ciphers. This wrapper provides the necessary glue
+ * tp work with such eSTREAM ciphers.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct stream_instance_ctx {
+   struct crypto_spawn alg;
+   unsigned int ivsize;
+};
+
+struct crypto_stream_ctx {
+   struct crypto_estream *child;
+};
+
+static int crypto_stream_setkey(struct crypto_tfm *parent, const u8 *key,
+   unsigned int keysize)
+{
+   struct crypto_stream_ctx *ctx = crypto_tfm_ctx(parent);
+   struct crypto_estream *child = ctx->child;
+   struct stream_instance_ctx *ictx =
+   crypto_instance_ctx(crypto_tfm_alg_instance(parent));
+   int err;
+
+   crypto_estream_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+   crypto_estream_set_flags(child, crypto_tfm_get_flags(parent) &
+CRYPTO_TFM_REQ_MASK);
+   err = crypto_estream_setkey(child, key, keysize, ictx->ivsize);
+   crypto_tfm_set_flags(parent, crypto_estream_get_flags(child) &
+CRYPTO_TFM_RES_MASK);
+   return err;
+}
+
+static int crypto_stream_crypt_walk(struct blkcipher_walk *walk,
+   struct crypto_estream *tfm)
+{
+   unsigned int bsize = crypto_estream_blocksize(tfm);
+   unsigned int nbytes = walk->nbytes;
+   u8 *src = walk->src.virt.addr;
+   u8 *dst = walk->dst.virt.addr;
+   u8 *iv = walk->iv;
+   u8 *ks;
+
+   crypto_estream_setiv(tfm, iv);
+   while (nbytes >= bsize) {
+   crypto_estream_encrypt_block(tfm, dst, src);
+   dst += bsize;
+   src += bsize;
+   nbytes -= bsize;
+   }
+   if (nbytes > 0) {
+   ks = kzalloc(bsize, GFP_KERNEL);
+   memcpy(ks, src, nbytes);
+   crypto_estream_encrypt_block(tfm, ks, ks);
+   memcpy(dst, ks, nbytes);
+   kfree(ks);
+   }
+
+   return 0;
+}
+
+static int crypto_stream_crypt(struct blkcipher_desc *desc,
+  struct scatterlist *dst,
+  struct scatterlist *src,
+  unsigned int nbytes)
+{
+   struct blkcipher_walk walk;
+   struct crypto_blkcipher *tfm = desc->tfm;
+   struct crypto_stream_ctx *ctx = crypto_blkcipher_ctx(tfm);
+   struct crypto_estream *child = ctx->child;
+   int err;
+
+   blkcipher_walk_init(&walk, dst, sr

[PATCH 3/3] [eSTREAM] salsa20: Salsa20 stream cipher algorithm

[Tan Swee Heng]

This patch implements the Salsa20 cipher algorithm. It has been
reworked to support the crypto_estream_* type instead of
crypto_cipher_*.
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 27a802f..eb7b132 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -467,6 +467,19 @@ config CRYPTO_SEED
  See also:
  
 
+config CRYPTO_SALSA20
+   tristate "Salsa20 stream cipher algorithm (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   select CRYPTO_ALGAPI
+   select CRYPTO_ESTREAM
+   help
+ Salsa20 stream cipher algorithm.
+
+ Salsa20 is a stream cipher submitted to eSTREAM, the ECRYPT
+ Stream Cipher Project. See 
+
+ The Salsa20 stream cipher algorithm is designed by Daniel J.
+ Bernstein <[EMAIL PROTECTED]>. See 
 
 config CRYPTO_DEFLATE
tristate "Deflate compression algorithm"
diff --git a/crypto/Makefile b/crypto/Makefile
index f95206b..adbe26a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_CRYPTO_TEA) += tea.o
 obj-$(CONFIG_CRYPTO_KHAZAD) += khazad.o
 obj-$(CONFIG_CRYPTO_ANUBIS) += anubis.o
 obj-$(CONFIG_CRYPTO_SEED) += seed.o
+obj-$(CONFIG_CRYPTO_SALSA20) += salsa20.o
 obj-$(CONFIG_CRYPTO_DEFLATE) += deflate.o
 obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
 obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
diff --git a/crypto/salsa20.c b/crypto/salsa20.c
new file mode 100644
index 000..6adf540
--- /dev/null
+++ b/crypto/salsa20.c
@@ -0,0 +1,225 @@
+/*
+ * Salsa20: Salsa20 stream cipher algorithm
+ *
+ * Copyright (c) 2007 Tan Swee Heng <[EMAIL PROTECTED]>
+ *
+ * Derived from:
+ * - salsa20.c: Public domain C code by Daniel J. Bernstein <[EMAIL PROTECTED]>
+ *
+ * Salsa20 is a stream cipher candidate in eSTREAM, the ECRYPT Stream
+ * Cipher Project. It is designed by Daniel J. Bernstein <[EMAIL PROTECTED]>.
+ * More information about eSTREAM and Salsa20 can be found here:
+ *   http://www.ecrypt.eu.org/stream/
+ *   http://cr.yp.to/snuffle.html
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SALSA20_IV_SIZE8
+#define SALSA20_BLOCK_SIZE64
+#define SALSA20_MIN_KEY_SIZE  16
+#define SALSA20_MAX_KEY_SIZE  32
+
+/*
+ * Start of code taken from D. J. Bernstein's reference implementation.
+ * With some modifications made to suit our needs.
+ */
+
+/*
+salsa20-ref.c version 20051118
+D. J. Bernstein
+Public domain.
+*/
+
+#define ROTATE(v,n) (((v) << (n)) | ((v) >> (32 - (n
+#define XOR(v,w) ((v) ^ (w))
+#define PLUS(v,w) (((v) + (w)))
+#define PLUSONE(v) (PLUS((v),1))
+#define U32TO8_LITTLE(p, v) \
+   { (p)[0] = (v >>  0) & 0xff; (p)[1] = (v >>  8) & 0xff; \
+ (p)[2] = (v >> 16) & 0xff; (p)[3] = (v >> 24) & 0xff; }
+#define U8TO32_LITTLE(p)   \
+   (((u32)((p)[0])  ) | ((u32)((p)[1]) <<  8) | \
+((u32)((p)[2]) << 16) | ((u32)((p)[3]) << 24)   )
+
+struct salsa20_ctx
+{
+   u32 input[16];
+};
+
+static void salsa20_wordtobyte(u8 output[64], const u32 input[16])
+{
+   u32 x[16];
+   int i;
+
+   memcpy(x, input, sizeof(x));
+   for (i = 20;i > 0;i -= 2) {
+   x[ 4] = XOR(x[ 4],ROTATE(PLUS(x[ 0],x[12]), 7));
+   x[ 8] = XOR(x[ 8],ROTATE(PLUS(x[ 4],x[ 0]), 9));
+   x[12] = XOR(x[12],ROTATE(PLUS(x[ 8],x[ 4]),13));
+   x[ 0] = XOR(x[ 0],ROTATE(PLUS(x[12],x[ 8]),18));
+   x[ 9] = XOR(x[ 9],ROTATE(PLUS(x[ 5],x[ 1]), 7));
+   x[13] = XOR(x[13],ROTATE(PLUS(x[ 9],x[ 5]), 9));
+   x[ 1] = XOR(x[ 1],ROTATE(PLUS(x[13],x[ 9]),13));
+   x[ 5] = XOR(x[ 5],ROTATE(PLUS(x[ 1],x[13]),18));
+   x[14] = XOR(x[14],ROTATE(PLUS(x[10],x[ 6]), 7));
+   x[ 2] = XOR(x[ 2],ROTATE(PLUS(x[14],x[10]), 9));
+   x[ 6] = XOR(x[ 6],ROTATE(PLUS(x[ 2],x[14]),13));
+   x[10] = XOR(x[10],ROTATE(PLUS(x[ 6],x[ 2]),18));
+   x[ 3] = XOR(x[ 3],ROTATE(PLUS(x[15],x[11]), 7));
+   x[ 7] = XOR(x[ 7],ROTATE(PLUS(x[ 3],x[15]), 9));
+   x[11] = XOR(x[11],ROTATE(PLUS(x[ 7],x[ 3]),13));
+   x[15] = XOR(x[15],ROTATE(PLUS(x[11],x[ 7]),18));
+   x[ 1] = XOR(x[ 1],ROTATE(PLUS(x[ 0],x[ 3]), 7));
+   x[ 2] = XOR(x[ 2],ROTATE(PLUS(x[ 1],x[ 0]), 9));
+   x[ 3] = XOR(x[ 3],ROTATE(PLUS(x[ 2],x[ 1]),13));
+   x[ 0] = XOR(x[ 0],ROTATE(PLUS(x[ 3],x[ 2]),18));
+   x[ 6] = XOR(x[ 6],ROTATE(PLUS(x[ 5],x[ 4]), 7));
+   x[ 7] = XOR(x[ 7],ROTATE(PLUS(x[ 6],x[ 5]), 9));
+   x[ 4] = XOR(x[ 4],ROTATE(PLUS(x[ 7],x[ 6]),13));

[PATCH 2/3] [eSTREAM] stream: Wrapper for eSTREAM ciphers

[Tan Swee Heng]

This patch implements a template that wraps around an eSTREAM cipher
algorithm and its ivsize.

For example, an eSTREAM cipher with the name CIPHERNAME and ivsize
IVSIZE will be instantiated as "stream(CIPHERNAME,IVSIZE)" in
cryptomgr. It uses blkcipher to walk over the memory it
encrypts/decrypts. It has been modified to use the crypto_estream_*
type instead of crypto_cipher_*.
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] [eSTREAM] estream: New crypto_type to support eSTREAM ciphers

[Tan Swee Heng]

This patch introduces a new crypto_type (and the associated *_alg and
*_tfm) to support eSTREAM ciphers.

It is created to provide better support for the setiv() operation
required by eSTREAM ciphers.
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1f32071..4ad25fd 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -40,6 +40,13 @@ config CRYPTO_HASH
tristate
select CRYPTO_ALGAPI
 
+config CRYPTO_ESTREAM
+   tristate "eSTREAM ciphers"
+   depends on EXPERIMENTAL
+   select CRYPTO_ALGAPI
+   help
+ This is a crypto_type to support eSTREAM ciphers.
+
 config CRYPTO_MANAGER
tristate "Cryptographic algorithm manager"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 1f87db2..14afa34 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_CRYPTO_BLKCIPHER) += blkcipher.o
 
 crypto_hash-objs := hash.o
 obj-$(CONFIG_CRYPTO_HASH) += crypto_hash.o
+obj-$(CONFIG_CRYPTO_ESTREAM) += estream.o
 
 obj-$(CONFIG_CRYPTO_MANAGER) += cryptomgr.o
 obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
diff --git a/crypto/estream.c b/crypto/estream.c
new file mode 100644
index 000..7ad70ff
--- /dev/null
+++ b/crypto/estream.c
@@ -0,0 +1,165 @@
+/*
+ * Cryptographic API.
+ *
+ * eSTREAM cipher operations.
+ *
+ * Copyright (c) 2007 Tan Swee Heng <[EMAIL PROTECTED]>
+ *
+ * Code derived from:
+ * cipher.c: Copyright (c) 2002 James Morris <[EMAIL PROTECTED]>
+ *   Copyright (c) 2005 Herbert Xu <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "internal.h"
+
+static int setkey_unaligned(struct crypto_tfm *tfm, const u8 *key,
+   unsigned int keysize, unsigned int ivsize)
+{
+   struct estream_alg *esa = &tfm->__crt_alg->cra_estream;
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+   int ret;
+   u8 *buffer, *alignbuffer;
+   unsigned long absize;
+
+   absize = keysize + alignmask;
+   buffer = kmalloc(absize, GFP_ATOMIC);
+   if (!buffer)
+   return -ENOMEM;
+
+   alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+   memcpy(alignbuffer, key, keysize);
+   ret = esa->setkey(tfm, alignbuffer, keysize, ivsize);
+   memset(alignbuffer, 0, keysize);
+   kfree(buffer);
+   return ret;
+
+}
+
+static int setkey(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keysize, unsigned int ivsize)
+{
+   struct estream_alg *esa = &tfm->__crt_alg->cra_estream;
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+
+   tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+   if (ivsize < esa->min_ivsize || ivsize > esa->max_ivsize) {
+   tfm->crt_flags |= CRYPTO_TFM_RES_BAD_IV_LEN;
+   return -EINVAL;
+   }
+   tfm->crt_estream.ivsize = ivsize;
+
+   tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+   if (keysize < esa->min_keysize || keysize > esa->max_keysize) {
+   tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+   return -EINVAL;
+   }
+   if ((unsigned long)key & alignmask)
+   return setkey_unaligned(tfm, key, keysize, ivsize);
+
+   return esa->setkey(tfm, key, keysize, ivsize);
+}
+
+static int setiv_unaligned(struct crypto_tfm *tfm, const u8 *iv)
+{
+   struct estream_alg *esa = &tfm->__crt_alg->cra_estream;
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+   u8 *buffer, *alignbuffer;
+   unsigned long absize;
+   unsigned int ivsize;
+   int ret;
+
+   ivsize = tfm->crt_estream.ivsize;
+   absize = ivsize + alignmask;
+   buffer = kmalloc(absize, GFP_ATOMIC);
+   if (!buffer)
+   return -ENOMEM;
+
+   alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+   memcpy(alignbuffer, iv, ivsize);
+   ret = esa->setiv(tfm, alignbuffer);
+   kfree(buffer);
+   return ret;
+}
+
+static int setiv(struct crypto_tfm *tfm, const u8 *iv)
+{
+   struct estream_alg *esa = &tfm->__crt_alg->cra_estream;
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+
+   if ((unsigned long)iv & alignmask)
+   return setiv_unaligned(tfm, iv);
+   return esa->setiv(tfm, iv);
+}
+
+static void encrypt_block_unaligned(struct crypto_tfm *tfm, u8 *dst,
+   const u8 *src)
+{
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+   struct estream_alg *esa = &tfm->__crt_alg->cra_estream;
+   unsigned int size = crypto_tfm_alg_blocksize(tfm);
+   u8 buffer[size + alignmask];
+   u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+
+   if (unlike

Re: [PATCH 1/2] stream: Stream cipher wrapper

[Tan Swee Heng]

Hi Herbert, thanks for taking the time to review my patches. My reply is below.

On Nov 11, 2007 8:11 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> In fact, thanks the work Joy has done with CTR, the Salsa20
> stream cipher can be expressed as
> ctr(salsa20,0,16,8)
> where salsa20 is the Salsa20 expansion function.
I agree that Salsa20 can be implemented this way as it is essentially
a hash function in counter mode. However this is not true in general
of other eSTREAM candidates. I am hoping to find a general solution
for eSTREAM ciphers, not just Salsa20.

> So could you please update your patches so that it works under
> this framework? So your salsa20 simple cipher should be OK as
> it is minus the extra bits like setiv.
I could do that. But before I do, may I propose an alternative approach?

I would like to propose using a separate crypto_type, say
crypto_estream_type, to "categorize" eSTREAM ciphers. Also separate
estream_alg and estream_tfm will be used to support the setiv() call
and to track the ivsize. A "stream" template will be used to specify
the algorithm and ivsize - so for example Salsa20 will be
"stream(salsa20,8)" to cryptomgr.

I think this is a valid approach as it allows eSTREAM ciphers to be
ported easily into the kernel without disturbing the existing block
ciphers and block modes. I also think it is feasible because I've
implemented it and tested it over the weekend. :P

Please consider the merits of such an approach. I will post my 3
patches in separate emails.

Regards,
Swee Heng
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

New Crypto Hardware

[Loc Ho]

Hi,

I am about to start developing a new device driver for new crypto hardware.
I am thinking of starting with Linux CryptoAPI interface. But I have the
following requirement:

1. Asynchronous encrypt/decrypt
2. Asynchronous hashing
3. Asynchronous combined mode (GCM, CCM, and GMAC) 4.
Asynchronous/synchronous public key accelaration (large vector operation) 5.
Support for additional algorithms - ARC4, Kasumi, AES-XCBC and etc 6. Other
minor offload such as windows check and etc. In fact, it can do packet level
processing as well.

What is the current state of asynchronous hashing? Will AEAD be changed to
make use of asynchronous hashing? Is anyone working on #1 and changing AEAD
to asychronous interface? In addition, most of the existent device driver
only use  synchronous interface. Are there any one changing them to
asynchronous crypto interface - such as NETKEY (Linux IPSec)?

Thanks,
Loc

-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] [crypto] S390-AES add fallback driver.

[Jan Glauber]

On Sun, 2007-11-11 at 22:10 +0100, Sebastian Siewior wrote:
> Some CPUs support only 128 bit keys in HW. This patch adds SW fallback
> support for the other keys which may be required. The generic algorithm
> (and the block mode) must be availble in case of a fallback.
> 
> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
> ---
> 
> Jan, please I didn't have the time to compile test. My compiler nagged
> only about the header file so it could work :)

Sebastian, thanks for working on this! Do you know if I need other
posted patches that are not yet in cryptodev-2.6 for this to work?

I'm asking becuase I'm getting the following crash using tcrypt (aes
192-bit key, ecb-mode) :(

Call Trace:
(Ý<02ee5680>¨ 0x2ee5680)
 Ý<0001008292ae>¨ crypto_ecb_setkey+0x52/0x74 Ýecb¨
 Ý<00010082316e>¨ setkey_fallback_blk+0x5e/0x98 Ýaes_s390¨
 Ý<000100886d76>¨ test_cipher+0x2da/0x8f0 Ýtcrypt¨
 Ý<00010080570e>¨ init+0x70e/0x1808 Ýtcrypt¨
 Ý<000674f4>¨ sys_init_module+0x148/0x1e64
 Ý<000222f8>¨ sysc_noemu+0x10/0x16
 Ý<0211ff6e>¨ 0x211ff6e

>From my limited understanding of the internals of crypto API I think
this is because crypto_ecb_setkey() calls crypto_cipher_setkey() instead
of crypto_blkcipher_setkey() and the layout of struct blkcipher_tfm
has the *iv where cipher_tfm has the setkey(). And oops, since the *iv
is zero we have a null pointer call. But maybe I'm just missing another patch...

thanks, Jan


> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
> index 812511b..393a450 100644
> --- a/arch/s390/crypto/aes_s390.c
> +++ b/arch/s390/crypto/aes_s390.c
> @@ -6,6 +6,7 @@
>   * s390 Version:
>   *   Copyright IBM Corp. 2005,2007
>   *   Author(s): Jan Glauber ([EMAIL PROTECTED])
> + *   Sebastian Siewior ([EMAIL PROTECTED]> SW-Fallback
>   *
>   * Derived from "crypto/aes_generic.c"
>   *
> @@ -18,6 +19,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "crypt_s390.h"
> @@ -34,45 +36,89 @@ struct s390_aes_ctx {
>   long enc;
>   long dec;
>   int key_len;
> + union {
> + struct crypto_blkcipher *blk;
> + struct crypto_cipher *cip;
> + } fallback;
>  };
> 
> -static int aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
> -unsigned int key_len)
> +/*
> + * Check if the key_len is supported by the HW.
> + * Returns 0 if it is, a positive number if it is not and software fallback 
> is
> + * required or a negative number in case the key size is not valid
> + */
> +static int need_fallback(unsigned int key_len)
>  {
> - struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
> - u32 *flags = &tfm->crt_flags;
> -
>   switch (key_len) {
>   case 16:
>   if (!(keylen_flag & AES_KEYLEN_128))
> - goto fail;
> + return 1;
>   break;
>   case 24:
>   if (!(keylen_flag & AES_KEYLEN_192))
> - goto fail;
> -
> + return 1;
>   break;
>   case 32:
>   if (!(keylen_flag & AES_KEYLEN_256))
> - goto fail;
> + return 1;
>   break;
>   default:
> - goto fail;
> + return -1;
>   break;
>   }
> + return 0;
> +}
> +
> +static int setkey_fallback_cip(struct crypto_tfm *tfm, const u8 *in_key,
> + unsigned int key_len)
> +{
> + struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
> + int ret;
> +
> + sctx->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> + sctx->fallback.blk->base.crt_flags |= (tfm->crt_flags &
> + CRYPTO_TFM_REQ_MASK);
> +
> + ret = crypto_cipher_setkey(sctx->fallback.cip, in_key, key_len);
> + if (ret) {
> + tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
> + tfm->crt_flags |= (sctx->fallback.blk->base.crt_flags &
> + CRYPTO_TFM_RES_MASK);
> + }
> + return ret;
> +}
> +
> +static int aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
> +unsigned int key_len)
> +{
> + struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
> + u32 *flags = &tfm->crt_flags;
> + int ret;
> +
> + ret = need_fallback(key_len);
> + if (ret < 0) {
> + *flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
> + return -EINVAL;
> + }
> 
>   sctx->key_len = key_len;
> - memcpy(sctx->key, in_key, key_len);
> - return 0;
> -fail:
> - *flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
> - return -EINVAL;
> + if (!ret) {
> + memcpy(sctx->key, in_key, key_len);
> + return 0;
> + }
> +
> + return setkey_fallback_cip(tfm, in_key, key_len);
>  }
> 
>  static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
>  {
>   const struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
> 
> + if (unlikely(need_fallback(sctx-

Re: [PATCH] HIFN: make Kconfig option depend on PCI

[Herbert Xu]

On Mon, Nov 12, 2007 at 01:31:49PM +, Jan Glauber wrote:
> The HIFN driver is currently selectable on s390 but wont compile.
> Since it looks like HIFN needs PCI make the Kconfig dependent on PCI,
> which is not available on s390.

Patch applied.  Thanks.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HIFN: make Kconfig option depend on PCI

[Evgeniy Polyakov]

On Mon, Nov 12, 2007 at 01:31:49PM +, Jan Glauber ([EMAIL PROTECTED]) wrote:
> The HIFN driver is currently selectable on s390 but wont compile.
> Since it looks like HIFN needs PCI make the Kconfig dependent on PCI,
> which is not available on s390.

Ugh, correct of course.
Thanks Jan.

ACK.

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] HIFN: make Kconfig option depend on PCI

[Jan Glauber]

The HIFN driver is currently selectable on s390 but wont compile.
Since it looks like HIFN needs PCI make the Kconfig dependent on PCI,
which is not available on s390.

-jang

Signed-off-by: Jan Glauber <[EMAIL PROTECTED]>

Index: cryptodev-2.6/drivers/crypto/Kconfig
===
--- cryptodev-2.6.orig/drivers/crypto/Kconfig
+++ cryptodev-2.6/drivers/crypto/Kconfig
@@ -88,6 +88,7 @@ config CRYPTO_DEV_HIFN_795X
select CRYPTO_DES
select CRYPTO_ALGAPI
select CRYPTO_ABLKCIPHER
+   depends on PCI
help
  This option allows you to have support for HIFN 795x crypto adapters.
 


-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html