[ACRYPTO] new release of asynchronous crrypto layer.

[ACRYPTO] new release of asynchronous crrypto layer.

[Evgeniy Polyakov]

Hello.

I'm pleased to announce new release of asynchronous crypto layer ACRYPTO
[1]. Acrypto allows to handle crypto requests asynchronously in
hardware.

This release has following major features:
 * OCF [2] to acrypto bridge. Work by Yakov Lerner <iler.ml@gmail.com>
   This module allows to use ixp4xx driver with acrypto IPsec and
   dm-crypt.
 * major name refactoring
 * crypto context abstractions (allows to notify hardware when keys 
   and/or some other crypto parameters are changed)
 * bugfixes and small feature extensions

With this release I decide to drop support for old tarball acrypto
releases. All new features and bugfixes will go directly into combined
patchsets against supported trees (currently 2.6.16 and 2.6.17, 2.6.15
is unsupported anymore). Releases with major changes will be announced
in linux-kernel@ and linux-crypto@ mail lists.

Combined patchsets include:
 * acrypto core
 * IPsec ESP4 port to acrypto
 * dm-crypt port to acrypto
 * OCF to acrypto bridge

Acrypto supports following crypto providers:
 * SW crypto provider
 * HIFN 795x adapters
 * VIA nehemiah CPU
 * SuperCrypt CE99C003B
 * devices supported by OCF (only IXP4xx was tested)

1. Acrypto homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=acrypto

2. OCF homepage.
http://ocf-linux.sourceforge.net

3. Acrypto archive with combined patchsets.
http://tservice.net.ru/~s0mbre/archive/acrypto/patchsets/

4. Acrypto archive with device drivers.
http://tservice.net.ru/~s0mbre/archive/acrypto/drivers/

Thank you.

-- 
	Evgeniy Polyakov

Re: [ACRYPTO] new release of asynchronous crrypto layer.

[Herbert Xu]

Hi Evgeniy:

Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> * IPsec ESP4 port to acrypto

I noticed a bug in the ESP IV processing.  When you do ESP asynchronously,
you can no longer use the last block of the previous packet as the IV of
the next.  This is because the next packet may have started processing
before the last packet has even been finalised.

A simple solution is to generate a random IV.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [ACRYPTO] new release of asynchronous crrypto layer.

[Evgeniy Polyakov]

On Tue, Jul 11, 2006 at 02:55:36PM +1000, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> Hi Evgeniy:

Hi Herbert.

> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> >
> > * IPsec ESP4 port to acrypto
> 
> I noticed a bug in the ESP IV processing.  When you do ESP asynchronously,
> you can no longer use the last block of the previous packet as the IV of
> the next.  This is because the next packet may have started processing
> before the last packet has even been finalised.

I cought that bug too, so IV being used is always copied into old_iv variable,
so integrity is stated.

> A simple solution is to generate a random IV.

Yes, it could be done too.
But actually neither random IV, nor IV created from encrypted previous packet, 
nor IV created from unencrypted previous packet are forbidden by spec. 
Initial implementation used constant IV there at all.

-- 
	Evgeniy Polyakov

Re: [ACRYPTO] new release of asynchronous crrypto layer.

[Herbert Xu]

Hi Evgeniy:

On Tue, Jul 11, 2006 at 09:31:57AM +0400, Evgeniy Polyakov wrote:
>
> > I noticed a bug in the ESP IV processing.  When you do ESP asynchronously,
> > you can no longer use the last block of the previous packet as the IV of
> > the next.  This is because the next packet may have started processing
> > before the last packet has even been finalised.
> 
> I cought that bug too, so IV being used is always copied into old_iv variable,
> so integrity is stated.

My point is that it is possible for two packets to use the same IV
under this scheme, which defeats the purpose of IVs.

> > A simple solution is to generate a random IV.
> 
> Yes, it could be done too.
> But actually neither random IV, nor IV created from encrypted previous packet, 
> nor IV created from unencrypted previous packet are forbidden by spec. 
> Initial implementation used constant IV there at all.

True.  However, using the same IV more than once is definitely not a good
idea.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt