Hi Nicolas, > On 3 Oct 2017, at 15:01, Nicolas Feignon <nicolas.feignon@xxxxxxxxxxxxxxxxx> 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-- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|