On Wed, Oct 10, 2007 at 07:21:47PM +0400, Evgeniy Polyakov wrote:
It passed all tests for AES, DES and DES3_EDE except weak test for DES,
since hardware can not determine weak keys.
Patch applied. Thanks Evgeniy!
BTW, we should change it so that the DES algorithm's setkey
function uses the
On Thu, Oct 11, 2007 at 06:14:00PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
On Wed, Oct 10, 2007 at 07:21:47PM +0400, Evgeniy Polyakov wrote:
It passed all tests for AES, DES and DES3_EDE except weak test for DES,
since hardware can not determine weak keys.
Patch applied. Thanks
On Thu, Oct 11, 2007 at 02:43:14PM +0400, Evgeniy Polyakov wrote:
Attached patch fixes that with following tcrypt output:
That was quick :)
Unfortunately it doesn't apply because des.c has been renamed
to des_generic.c in cryptodev-2.6. Could you please fix that
up and also move the
On Thu, Oct 11, 2007 at 06:52:02PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
On Thu, Oct 11, 2007 at 02:43:14PM +0400, Evgeniy Polyakov wrote:
Attached patch fixes that with following tcrypt output:
That was quick :)
Unfortunately it doesn't apply because des.c has been renamed
to
* Herbert Xu | 2007-10-11 19:47:00 [+0800]:
I'm not quite happy with adding keysize to the core API though.
At some point I'd like to see the DMA operations folded into the
API as well so having a key is going to be far from universal.
ACK
In fact the compression operation is an existing example
On Thu, Oct 11, 2007 at 03:28:48PM +0200, Sebastian Siewior wrote:
It is possible that future machines will support 192 and 256 key sizes
as well but what do I know, I don't work there :) Anyway even if they
support all key sizes at later time you have still those who don't. On
the other hand
On Thu, Oct 11, 2007 at 02:43:14PM +0200, Sebastian Siewior wrote:
In other words, let's make geode-aes use the padlock-sha method
and just fall back to a lower-priority AES algorithm if it sees
a key size that it can't handle.
geode and s390 :)
Are you sure about s390? I can't find a key
