> > In fact, using the current cts template around the current xts template actually does NOT > > implement standards compliant XTS at all, as the CTS *implementation* for XTS is > > different from the one for CBC as implemented by the current CTS template. > > The template is just a name. The implementation can do whatever it > wants for each instance. So obviously we would employ a different > implementation for xts compared to cbc. > 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? For ECB and CBC I suppose that's techically possible. But then what do I get when I try to wrap CTS around some block cipher mode it doesn't recognise? Tricky ... 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. For decryption, you actually first need to decrypt the last block with the last tweak before you can decrypt the 2nd last block with the 2nd last tweak. Not sure how you intend to handle that with some generic wrapper around "xts". > > Cheers, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > 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
Attachment:
PGP.sig
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
