On Thu, Nov 22, 2007 at 02:57:07PM +0300, Evgeniy Polyakov wrote: > > Somehow you described that to others - just combine things together and > put to Documentation/crypto and that will be enough. Patches are welcome :) > For example this patchset looks like possible first step in proper > chaining mechanism for hardware devices, but if this will be impemented > this way, then each hardware completion callback should be wrapped with > proper geniv methods (like those which copy iv back to req->info). Is > this right approach (for those users who care about correct returned > IV), or will it just use software implementation only? I'm not sure I understand your question. First of all givcrypt is designed to work for hardware devices too. If they can generate their own IVs then they should directly hook up to the givcrypt method and use the givcipher type. If not then they can use one of the precanned geniv wrappers and declare their preference in the in crypto_ablkcipher_alg->geniv. As to chaining, I presume you mean something like encryption followed by hashing? If so then this really doesn't have much to do with chaining at all. I think we don't really need chaining in general because the hardware doesn't do arbitrary chaining. Instead what they do is specific chains that are useful for particular applications. Case in point would be encryption followed by hashing which is designed for IPsec. Therefore instead of having a general chaining abstraction I've chosen to do chaining support on a case-by-case basis. For instance, the above chaining is now supported by the new crypto_aead transform type. It just so happens that people are also designing algorithms to make crypto_aead useful for software as well which is a bonus :) 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
