Inconsistent content of gocryptfs.diriv

[yousong]

I use gocryptfs 2.4.0 -reverse and backup the encrypted content to cloud storage. Not sure how it got to such a state, I found with hexdump that content of gocryptfs.diriv of one directory was wrong, while entry names in the directory were encrypted using correct diriv. The check was also done on local gocryptfs reverse mount and the result was the same.

Wrong gocryptfs.diriv content:

1. gocryptfs complains that pad len value of decrypted names was incorrect, e.g.

   decryptName "N1ZkQWcCyKkTNLokEkdWGPcKJZ8BeI-8Jcgtbb0w4MQ": unPad16 error: Padding too long, padLen=128 > 16
   OpenDir "ciMV2NiraaRnS6losd2YZw": invalid entry "N1ZkQWcCyKkTNLokEkdWGPcKJZ8BeI-8Jcgtbb0w4MQ": bad message

2. sha256(ENC_DIR_NAME+"\x00DIRIV") was incorrect (internal/pathiv/pathiv.go:Derive())

Entry names were encrypted using correct diriv: I restarted gocryptfs, content of gocryptfs.diriv now matches the code implementation, and at the same time entry names are the same as those before the restart.

[rfjakob]

Can you reproduce this issue? If yes, how?

And this:

I restarted gocryptfs

You restarted the "gocryptfs -reverse" side, right?

[rfjakob]

I reverse-mounted my whole "/" like this:

gocryptfs -init -reverse /
gocryptfs -reverse / /tmp/reverse-rootfs
gocryptfs /tmp/reverse-rootfs /tmp/reverse-rootfs-dec

Then,

find /tmp/reverse-rootfs-dec > /dev/null

got me this in the syslog:

decryptName "BnQBbK9CRa7o3xM-SKy_URe-O_NJhAuZPvY45tpbSSc6ltK2Uns56dwSdpYjq1htoB8QOdFW8muaONDM6stYTI8xUdKgv7jePyEycN67ZGXzIvRxYqXAyrfbN6Mwu6o_xJM4GDkJpiRNwIQ8EDVPqkrt_hAcQJLzzZwzqt3IM-07a6zYmOJshl7u-qW_Rndyt99uT4Qnq_aRsvT7P08zYrpRhlx8aXJLPXGbHEcjnlUWewXmXndV55LpnIcG4B9eSTednHnmFfdwUpj90DQXVpfus0knnQQaXujw2z23JH05AdAHk8T-RIwCOKOykJJp": unPad16 error: Padding too long, padLen=102 > 16

OpenDir "MZfinlaIaTJ1efqurB5Xyhalox1MwxlPVWqSfQbPw7w": invalid entry "BnQBbK9CRa7o3xM-SKy_URe-O_NJhAuZPvY45tpbSSc6ltK2Uns56dwSdpYjq1htoB8QOdFW8muaONDM6stYTI8xUdKgv7jePyEycN67ZGXzIvRxYqXAyrfbN6Mwu6o_xJM4GDkJpiRNwIQ8EDVPqkrt_hAcQJLzzZwzqt3IM-07a6zYmOJshl7u-qW_Rndyt99uT4Qnq_aRsvT7P08zYrpRhlx8aXJLPXGbHEcjnlUWewXmXndV55LpnIcG4B9eSTednHnmFfdwUpj90DQXVpfus0knnQQaXujw2z23JH05AdAHk8T-RIwCOKOykJJp": bad message

Looks like a bug in long name handling, but I'm not sure that's what you are seeing, because your names were short.

[rfjakob]

One more thing I want to mention: With the filesystems mounted like shown above, when you run

ls -R /tmp/reverse-rootfs

you will see a lot of this in syslog:

decryptName "WJX9T5u6q-n1-T1kWRb2mdVL2DkWNZNpIGGAEcEq0huQU_mrqXyBQyDfg2yXPNZWcmIk0_dMKb6Bzu7WjEDDFZfqA7O76wke5An5xOE9yYB0mowj0wbuATMOwOlwlO-k": unPad16 error: Padding too long, padLen=120 > 16

decryptName "xo4AFpka-7Y2x3UYX3Kkp78qx1_NhNB26A4DrGnMwKXiqd2Y9hCEactfUFoQg68g9lAbWRURK-0p-9ctFcAQrvvwSWR0HquVSFgWdtex9JyAveJ8appH26FaQKfKQN8r": unPad16 error: Padding too long, padLen=31 > 16

decryptName "bmMKugIEq2cu_1POA27K5xTQnmo8Gd3SdYJ66WKf_t4rlFAEVtILzhh_MUu1SCOT-s9ueIV_zQSbRdsKOJTUUA": unPad16 error: Padding too long, padLen=100 > 16

This is the result of "ls" trying to follow encrypted symlinks (which fail to resolve, of course). So these messages are normal, but the OpenDir error above is not.

[yousong]

Can you reproduce this issue? If yes, how?

And this:

I restarted gocryptfs

You restarted the "gocryptfs -reverse" side, right?

Yes, gocryptfs -reverse was restarted. I tried to debug it and collect as much info as I can before the restart. After the restart, content of gocryptfs.diriv changed to its desired state like the code implementation and the encrypted names remained the same like before the restart.

Looks like a bug in long name handling, but I'm not sure that's what you are seeing, because your names were short.

I have long names in the directory. The padded encrypted names can be as long as 112 bytes (16*7). No symlink was involved as far as I can remember and I just checked with find . -type l