* 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 - 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
