Hello.
I am pleased to announce new release of the acrypto for 2.6.19 kernel -
first asynchronous crypto layer for Linux kernel 2.6.
Acrypto allows to handle crypto requests asynchronously in hardware.
Acrypto supports following features:
* multiple asynchronous crypto device queues
* crypto session routing (allows to complete single crypto session when
several operations (crypto, hmac, anything) are completed)
* crypto session binding (bind crypto processing to specified device)
* modular load balancing (one can created load balancer which will get
into account for example pid of the calling process)
* crypto session batching genetically implemented by design (acrypto
provides the whole data structure to crypto device, i.e. it is
possible to use acrypto as a bridge which routes requests between
completely different devices, since it does not differentiate between
users, just handles requests)
* crypto session priority
* different kinds of crypto operation(RNG, asymmetrical crypto, HMAC and
any other)
Combined patchset includes:
* acrypto core
* IPsec ESP4 port to acrypto
* dm-crypt port to acrypto
* OCF to acrypto bridge, which allows to run OCF device
drivers with acrypto (for example ixp4xx), requires OCF installed.
Ported crypto drivers and benchmarks can be found on acrypto homepage:
http://tservice.net.ru/~s0mbre/old/?section=projects&item=acrypto
Changes from previous release:
* moved to 2.6.19 crypto API where it is used
* updated XFRM engine
* bugfixes
2.6.16 - 2.6.18 releases moved to maintenance mode.
Patchset is not attached due to its size (192kb).
Signed-off-by: Evgeniy Polyakov <[email protected]>
--
Evgeniy Polyakov
Does acrypto still have the same size restrictions
I ran into with the last release?
Thanks, Andreas
On Mon, Dec 18, 2006 at 08:38:54AM +0100, Andreas Jellinghaus ([email protected]) wrote:
> Does acrypto still have the same size restrictions
> I ran into with the last release?
Actually I do not recall what is 'size retrictions' - if you talk about
possibility to use software crypto provider, which supports one cipher
in a time, then yes, but it is intended to be used with hardware though.
Otherwise I do not recall any problems pointed to me.
> Thanks, Andreas
--
Evgeniy Polyakov
Evgeniy Polyakov wrote:
> Actually I do not recall what is 'size retrictions' - if you talk about
> possibility to use software crypto provider, which supports one cipher
> in a time, then yes, but it is intended to be used with hardware though.
> Otherwise I do not recall any problems pointed to me.
sorry, "size restriction" was the wrong term. acrypto only supports
"sync provider only supports AES-128 in CBC mode, so if you try
different ciphers, there can be some problems."
and I'm using dm-crypto with aes-cbc-essiv:sha256 and your acrypto patch
breaks this setup - not only acrypto doesn't provide crypto capability
for my setup, but with this patch it is not offered by the old mechanism
either, so my system has no way to decrypt the root partition. note:
that was with the 2.6.18 patch, no idea if it is different now.
so while the patch adds new features, it also removes some features -
not sure if always (via patch) or via compile option or via module
load. also I'm not sure if acrypto can be disabled via kernel command
line to get the old behaviour (including aes-cbc-essiv:sha256 support
for dm-crypt).
would be nice to track those issues, so people testing your patch
are aware of the situation.
Regards, Andreas
On Mon, Dec 18, 2006 at 02:00:26PM +0100, Andreas Jellinghaus ([email protected]) wrote:
> Evgeniy Polyakov wrote:
> >Actually I do not recall what is 'size retrictions' - if you talk about
> >possibility to use software crypto provider, which supports one cipher
> >in a time, then yes, but it is intended to be used with hardware though.
> >Otherwise I do not recall any problems pointed to me.
>
> sorry, "size restriction" was the wrong term. acrypto only supports
> "sync provider only supports AES-128 in CBC mode, so if you try
> different ciphers, there can be some problems."
You can change it in async_provider in compilation time or I can create
module version. There is an item in related todo list to use crypto
contexts, they were created exactly for such kind of things (actually
for hardware devices which do not support realtime key changes).
> and I'm using dm-crypto with aes-cbc-essiv:sha256 and your acrypto patch
> breaks this setup - not only acrypto doesn't provide crypto capability
> for my setup, but with this patch it is not offered by the old mechanism
> either, so my system has no way to decrypt the root partition. note:
> that was with the 2.6.18 patch, no idea if it is different now.
>
> so while the patch adds new features, it also removes some features -
> not sure if always (via patch) or via compile option or via module
> load. also I'm not sure if acrypto can be disabled via kernel command
> line to get the old behaviour (including aes-cbc-essiv:sha256 support
> for dm-crypt).
>
> would be nice to track those issues, so people testing your patch
> are aware of the situation.
I will change acrypto software crypto provider, but right now, yes,
software crypto only supports one mode.
> Regards, Andreas
--
Evgeniy Polyakov
Evgeniy Polyakov wrote:
> You can change it in async_provider in compilation time or I can create
> module version. There is an item in related todo list to use crypto
> contexts, they were created exactly for such kind of things (actually
> for hardware devices which do not support realtime key changes).
ok, what do I need to change to get aes-cbc-essiv:sha256 support
so I can use acrypto with my current dm-crypt'ed partitions?
>> would be nice to track those issues, so people testing your patch
>> are aware of the situation.
>
> I will change acrypto software crypto provider, but right now, yes,
> software crypto only supports one mode.
ok, thanks.
Regards, Andreas
On Tue, Dec 19, 2006 at 11:51:01AM +0100, Andreas Jellinghaus ([email protected]) wrote:
> Evgeniy Polyakov wrote:
> >You can change it in async_provider in compilation time or I can create
> >module version. There is an item in related todo list to use crypto
> >contexts, they were created exactly for such kind of things (actually
> >for hardware devices which do not support realtime key changes).
>
> ok, what do I need to change to get aes-cbc-essiv:sha256 support
> so I can use acrypto with my current dm-crypt'ed partitions?
For AES CBC only set of supported operations should be extended.
Something like patch below:
diff --git a/acrypto/async_provider.c b/acrypto/async_provider.c
index ac11708..186cc5c 100644
--- a/acrypto/async_provider.c
+++ b/acrypto/async_provider.c
@@ -48,6 +48,12 @@ static struct acrypto_capability prov_caps[] = {
{ACRYPTO_OP_ENCRYPT, ACRYPTO_TYPE_AES_128, ACRYPTO_MODE_CBC, 1000},
{ACRYPTO_OP_DECRYPT, ACRYPTO_TYPE_AES_128, ACRYPTO_MODE_CBC, 1000},
+
+ {ACRYPTO_OP_ENCRYPT, ACRYPTO_TYPE_AES_192, ACRYPTO_MODE_CBC, 1000},
+ {ACRYPTO_OP_DECRYPT, ACRYPTO_TYPE_AES_192, ACRYPTO_MODE_CBC, 1000},
+
+ {ACRYPTO_OP_ENCRYPT, ACRYPTO_TYPE_AES_256, ACRYPTO_MODE_CBC, 1000},
+ {ACRYPTO_OP_DECRYPT, ACRYPTO_TYPE_AES_256, ACRYPTO_MODE_CBC, 1000},
};
static int prov_cap_number = sizeof(prov_caps)/sizeof(prov_caps[0]);
--
Evgeniy Polyakov