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

2007-11-12 Thread 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 ab

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

2007-11-12 Thread 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.

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

2007-11-12 Thread 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

Re: New Crypto Hardware

2007-11-12 Thread 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 whic

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

2007-11-12 Thread 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

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

2007-11-12 Thread 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 instan

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

2007-11-12 Thread 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

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

2007-11-12 Thread 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.

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

2007-11-12 Thread 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 ++

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

2007-11-12 Thread 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 Sals

New Crypto Hardware

2007-11-12 Thread 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. Asynchronou

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

2007-11-12 Thread 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

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

2007-11-12 Thread 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.opensw

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

2007-11-12 Thread 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.

[PATCH] HIFN: make Kconfig option depend on PCI

2007-11-12 Thread 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 ===