* Jan Glauber | 2007-03-19 15:25:39 [+0100]: >Having fall back support for unsupported parts of an algorithm sounds like >the right thing to me. In include/linux/crypto.h I found: > >/* > * Set this bit if and only if the algorithm requires another algorithm of > * the same type to handle corner cases. > */ >#define CRYPTO_ALG_NEED_FALLBACK 0x00000100 > >which is currently not used but looks like someone has thought of implementing >that kind of fallback method? This is not totally true. padlock-sha makes uses of that flag and something forbids that padlock-sha gets itself back as fall back. I did not find out where and how does it check for hat flag, but it does. >OTOH, if aes and padlock are the only two cornercases it may be easier to >implement the fallback manually. Are there other algorithms / hardware accelerators >that would benefit from a generic fallback method? I wouldn't consider s390'aes and Geode'aes as corner cases because they never claimed to supported those key sizes. A good example of a corner case is padlock-sha.c I guess. They support sha1 & sha256 on hardware as long as the data is not larger than one page. On the other hand they maybe different interpretation of a corner case and whether an algorithm like aes, that is standardized for 128, 192 and 256 bits, has to support all of them or may support just a subset. We need definitely some sort of fall back method, the question is just if the driver should implement it or the API if the driver already knows that it can't be handled at all. And I would like to find out how the flag gets actually checked :) >Cheers, >Jan -- Regards Sebastian Siewior - 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
