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)
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.
Thanks,
--
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
