On Sun, Nov 18, 2007 at 02:52:37PM +0800, Herbert Xu (herbert@xxxxxxxxxxxxxxxxxxx) wrote:
> On Fri, Nov 16, 2007 at 02:11:10PM +0300, Evgeniy Polyakov wrote:
> >
> > That's a question - should it copy IV back or not?
> > Currently it is not required by crypto users.
>
> OK I've changed my mind :)
>
> The reason is CTR, or rather the CTR as used by IPsec. CTR
> itself should be able to chain, in fact one of the things I'll
> do later is to move most of the current CTR code into a chainable
> CTR with just the algorithm parameter, i.e., ctr(aes) which would
> be what we currently call ctr(0,16,16). We can then put a non-
> chainable wrapper around that, perhaps ctr-ipsec(aes).
>
> In any case, it is clear that some algorithms simply won't be
> able to chain because the IV exposed to the outside is not the
> complete IV.
>
> So my plan is to add a new flag, CRYPTO_ALG_CIPHER_NOCHAIN that
> you would set on algorithms that cannot be chained. The semantics
> is that everything else remains the same except that on encrypt
> calls, the req->info after completion is undefined.
>
> Users requiring chaining would then do
>
> crypto_alloc_blkcipher("foo", 0, CRYPTO_ALG_CIPHER_NOCHAIN)
Hmm, users who want chaining will set flag _NOCHAIN :)
I would call it something more informative...
> For hardware offload devices such as yours where chaining does
> not come naturally you could then elect to not implement chaining
> and just set the flag.
>
> Please let me know if you see any problems with this approach.
I'm not sure what user will do, when it request chaining, but driver
will set CRYPTO_ALG_CIPHER_NOCHAIN itself and return wrong/old in
req->info?
For IPsec it is not an issue though, but I can not say that for all.
--
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
