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

Horia Geantă horia.geanta at freescale.com
Wed Mar 4 02:44:21 AEDT 2015


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.

Let's not forget what XTS standard says about IVs / tweak values:
- each data unit (sector in this case) is assigned a non-negative tweak
value and
- tweak values are assigned *consecutively*, starting from an arbitrary
non-negative value
- there's no requirement for tweak values to be unpredictable

Thus, in theory ESSIV is not supposed to be used with XTS mode: the IVs
for consecutive sectors are not consecutive values.
In practice, as Milan said, the combination is sometimes used. It
functions correctly in SW (and also in talitos as long as req. data size
<= sector size).

>> Maybe the following question would be if the dmcrypt sector IV algorithms
>> should moved into crypto API as well.
>> (But because I misused dmcrypt IVs hooks for some additional operations
>> for loopAES and old Truecrypt CBC mode, it is not so simple...)
> 
> Speaking again with talitos in mind, there would be no advantage for this
> hardware.  Although larger requests are possible only a single IV can be
> provided per request, so for algorithms like AES-CBC and dm-crypt 512byte IOs
> are the only option (short of switching to 4kB block size).

Right, as explained above talitos does what the XTS mode standard
mandates. So it won't work properly in case of cbc-aes:essiv with
request sizes larger than sector size.

Still, in SW at least, XTS could be improved to process more sectors in
one shot, regardless of the IV scheme used - as long as there's a
IV.next() function and both data size and sector size are known.

Horia



More information about the Linuxppc-dev mailing list