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~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
