Issue with encrypted filenames on UBIFS

[Nicolas Feignon]

I was indeed using a hardware crypto accelerator on a Atmel SAMA5D2 platform.
It works correctly after removing it. I'll work on a patch.

Thank you!
Nicolas

2017-10-03 17:42 GMT+02:00 David Gstir <david at sigma-star.at>:
> Hi Nicolas,
>
>> On 3 Oct 2017, at 15:01, Nicolas Feignon <nicolas.feignon at mobile-devices.fr> wrote:
>>
>> Hi,
>>
>> I'm encountering an issue with filesystem encryption on UBIFS. I'm using Kernel
>> 4.13.3.
>>
>> The encryption of filenames does not work correctly for filenames of more that
>> 16 characters. It works fine if the names are shorter. Here's what I get:
>>
>> [~/writeDir]# touch aaaaaaaaaaaaaaaa # 16 characters
>> [~/writeDir]# ls
>> ls: cannot access aaaaaaaaaaaaaaaa>*0ѐL9: No such file or directory
>> aaaaaaaaaaaaaaaa?>??*0?????n??L9
>>
>> I set the policy with:
>> [~]# openssl rand 64 > key
>> [~]# fscryptctl insert_key < key
>> a5bb6bff407f6f67
>> [~]# fscryptctl set_policy a5bb6bff407f6f67 writeDir/
>>
>> I get the issue for all encryption modes and padding values altough the length
>> of filenames at which it doesn't work varies.
>> With the default padding of 32 and AES-256-CTS encryption mode, it does not
>> work for length >= 16 and <= 32, length >= 48 and <= 64...
>>
>> I took a look at fs/crypto/fname.c but I can't figure out the problem. It seems
>> like it's an overflow somewhere.
>
> Do you use a hardware crypto accelerator for AES? I saw the same issue with the CAAM driver (see issue 1 here [1]) some time ago.
>
> Specifically, the blockcipher driver code is required to update ->iv of skcipher_request after encryption/decryption. This is used by the CTS-mode code. Here's the fix that got merged for the CAAM driver [2].
>
> - David
>
> [1] https://marc.info/?l=linux-crypto-vger&m=149640631518134&w=2
> [2] https://marc.info/?l=linux-crypto-vger&m=149865646825902&w=2