On Thu, Nov 22, 2007 at 08:09:37PM +0800, Herbert Xu ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
