On Thu, Nov 22, 2007 at 08:09:37PM +0800, Herbert Xu (herbert@xxxxxxxxxxxxxxxxxxx) wrote: > 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 :) I still do not understand thow whole concept. > > 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. But for example chainiv_givcrypt() will not return correct iv when called fro async device, since when givcrypt() returned operation is not yet completed. > 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. Yes, that what I meant. And also other possible crypto modes, which can require iv-based tweaks. > 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 :) This sheds some light on, thanks. -- Evgeniy Polyakov - 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
