Hello Herbert,
this is my first attempt.
patch 1 - the main patch (touching core api)
patch 2 - fixing remaining crypto infrastructure
patch 3 - fixing some users
Almost all users are easy to fix. The wlan stack allocates the cipher at
one time and sets the key at another time. So I don't know the requested
keysize at allocation time.
In the fixup, crypto_authenc_alloc() got a little ugly. The keysize is
only consider for the blkcipher but the hash might also be limited. Tell
me what you thing about this one. Maybe something like cbc(aes|192) is a
better solution.
Sebastian
Fix the core crypto API and add keysize parameter.
---
crypto/authenc.c | 7 ++++---
crypto/cbc.c | 4 ++--
crypto/cryptd.c | 8 ++++----
crypto/cryptomgr.c | 2 +-
crypto/hmac.c | 4 ++--
crypto/lrw.c | 4 ++--
crypto/pcbc.c | 5 +++--
crypto/xcbc.c | 4 ++--
crypto/xts.c | 4 ++--
9 files changed, 22 insertions(+), 20 deletions(-)
Add the keysize parameter to "lookup" functions within the core
crypto API.
---
crypto/algapi.c | 7 +++--
crypto/api.c | 52 ++++++++++++++++++++++++++++++++++------------
crypto/cbc.c | 2 +-
crypto/cryptomgr.c | 3 +-
crypto/ecb.c | 4 +-
crypto/hmac.c | 2 +-
crypto/internal.h | 7 ++++-
include/crypto/algapi.h | 9 ++++---
include/linux/crypto.h | 17 +++++++++------
9 files changed, 68 insertions(+), 35 deletions(-)
and fix dm-crypt, wlan stack and trcypt
---
crypto/tcrypt.c | 26 +++++++++++++++-----------
drivers/md/dm-crypt.c | 2 +-
include/linux/crypto.h | 6 +++---
net/ieee80211/ieee80211_crypt_tkip.c | 4 ++--
net/ieee80211/ieee80211_crypt_wep.c | 6 ++++--
5 files changed, 25 insertions(+), 19 deletions(-)
Hi Sebastian:
On Wed, Oct 10, 2007 at 06:44:00PM +0200, Sebastian Siewior wrote:
>
> Almost all users are easy to fix. The wlan stack allocates the cipher at
> one time and sets the key at another time. So I don't know the requested
> keysize at allocation time.
Thanks for the patch!
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.
In fact the compression operation is an existing example of a
user that doesn't have a key.
> In the fixup, crypto_authenc_alloc() got a little ugly. The keysize is
> only consider for the blkcipher but the hash might also be limited. Tell
> me what you thing about this one. Maybe something like cbc(aes|192) is a
> better solution.
We could do that.
However, I think the number of extant devices that actually
need this is so small that we can solve it using the fallback
flag instead.
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.
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
* 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 of a
>user that doesn't have a key.
ACK
>> In the fixup, crypto_authenc_alloc() got a little ugly. The keysize is
>> only consider for the blkcipher but the hash might also be limited. Tell
>> me what you thing about this one. Maybe something like cbc(aes|192) is a
>> better solution.
>
>We could do that.
Than we will end up with cbc(aes|192) and cbc(aes|128) being the same
algorithm in most cases (boxes)....
>However, I think the number of extant devices that actually
>need this is so small that we can solve it using the fallback
>flag instead.
>
>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 :)
I'm currently digging in geode's code, it seems that there is bug
hiding somewhere.
>Cheers,
Sebastian
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 size that it can't
handle.
> I'm currently digging in geode's code, it seems that there is bug
> hiding somewhere.
I wouldn't be surprised if there were two of them hiding there :)
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
* Herbert Xu | 2007-10-11 21:01:40 [+0800]:
>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 size that it can't
>handle.
Yes I am. If you take a look the comment in the driver's init functions
you will see
/* z9 109 and z9 BC/EC only support 128 bit key length */
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 the customers maybe don't even care / use it :)
>Cheers,
Sebastian
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 the customers maybe don't even care / use it :)
OK they'll get the fallback treatment then :)
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