> >
> > Hmmm ... so the generic CTS template would have to figure out whether it is
> > wrapped
> > around ECB, CBC, XTS or whatever and then adjust to that?
>
> That's not hard to do. Right now cts only supports cbc. IOW
> if you pass it anything else it will refuse to instantiate.
>
Ah, I see it now:
if (strncmp(alg->base.cra_name, "cbc(", 4))
goto err_drop_spawn;
So you cannot even do cts(xts) at the moment.
> > For XTS, you have this additional curve ball being thrown in called the
> > "tweak".
> > For encryption, the underlying "xts" would need to be able to chain the
> > tweak,
> > from what I've seen of the source the implementation cannot do that.
>
> You simply use the underlying xts for the first n - 2 blocks and
> do the last two by hand.
>
Possible, but then you're basically pulling a generic XTS implementation into
cts.c,
since XTS is nothing more than the repeated application of just that.
Same thing would apply to any other mode you eventually need cts for.
But I suppose it would save you the trouble of having to add cts to all
individual
optimized software implementations of xts-which-is-not-really-xts, so I can see
WHY you would want to do it that way ...
Tthen there's still the issue of advancing that last tweak. From what I've seen,
the xts implementation does not output the last tweak so you would have to
recompute it locally in cts.c as block_cipher_enc(iv) * alpha^j. Which is
wasteful.
Of course this could be solved by redefining xts to output the last tweak
like CBC/CTR output their last IV ... Which would probably give us HW guys
trouble again because our HW cannot do *that* ... (While the HW very likely
*does* implement the cipher text stealing properly, just to be able to boast
about IEEE P1619 compliance ...)
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
