[PATCH 0/2] crypto: talitos: Add AES-XTS mode

Horia Geantă horia.geanta at freescale.com
Mon Mar 9 21:16:04 AEDT 2015


On 3/3/2015 7:44 PM, Martin Hicks wrote:
> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
> <horia.geanta at freescale.com> 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.

Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
to 8 bytes.
So I guess ESSIV won't work with talitos-xts, since the encrypted IV
output is 16 bytes.
But as previously said, ESSIV breaks the XTS standard requirement for
having a consecutive IV for consecutive blocks. ESSIV should really be
used only with disk-level encryption schemes that require an
unpredictable IV.

> 
> 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.

XTS IV *is* 16 bytes. The fact that xts-talitos can handle only 8 bytes
is a problem indeed, but for plain and plain64 should not matter.

Horia




More information about the Linuxppc-dev mailing list