On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă <horia.geanta@xxxxxxxxxxxxx> wrote: > On 3/3/2015 12:09 AM, Martin Hicks wrote: >> >> On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote: >>> >>> If crypto API allows to encrypt more sectors in one run >>> (handling IV internally) dmcrypt can be modified of course. >>> >>> But do not forget we can use another IV (not only sequential number) >>> e.g. ESSIV with XTS as well (even if it doesn't make much sense, some people >>> are using it). >> >> Interesting, I'd not considered using XTS with an IV other than plain/64. >> The talitos hardware would not support aes/xts in any mode other than >> plain/plain64 I don't think...Although perhaps you could push in an 8-byte >> IV and the hardware would interpret it as the sector #. >> > > For talitos, there are two cases: > > 1. request data size is <= data unit / sector size > talitos can handle any IV / tweak scheme > > 2. request data size > sector size > since talitos internally generates the IV for the next sector by > incrementing the previous IV, only IV schemes that allocate consecutive > IV to consecutive sectors will function correctly. > it's not clear to me that #1 is right. I guess it could be, but the IV length would be limited to 8 bytes. This also points out that claiming that the XTS IV size is 16 bytes, as my current patch does, could be problematic. It's handy because the first 8 bytes should contain a plain64 sector #, and the second u64 can be used to encode the sector size but it would be a mistake for someone to use the second 8 bytes for the rest of a 16byte IV. mh -- Martin Hicks P.Eng. | mort@xxxxxxxx Bork Consulting Inc. | +1 (613) 266-2296 -- 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
