directory iv may be lost when using cloud sync apps

[yanjiew1]

Think of the following situation:

Computer A and Computer B shares some file using cloud sync apps.
They use gocryptfs to encrypt the files on the cloud.

1. Computer A and Computer B are both offline.
2. Create a directory in the root directory named "Example" in the Computer A.
3. Store some files in "/Example"
4. Create a directory in the root directory named "Example" in the Computer B.
5. Store some files in "/Example"
6. Make Computer A and Computer B online.

The conflict happened because of the same file name "gocryptfs.diriv," which stores the iv to decrypt the filename.
If one computer overwrites the gocryptfs.diriv that another computer uploads, the directory iv will be lost.

[rfjakob]

That is correct, could happen. The worst thing that could happen is losing the file names. The file contents can always be recovered.

[rfjakob]

As I don't see a way to fix this I'll declare this a known limitation and close the ticket.

[danim7]

Hello, Just wondering why it is not possible to use the deterministic encryption "-aessiv" flag to avoid that problem? I thought it would overwrite with the same gocryptfs.diriv file, even if it was generated from a different computer, but it doesn't...it is not as deterministic as in reverse mode...just wondering why? Best regards!

[rfjakob]

Looks like this could be fixed, or at least mitigated, by creating the diriv deterministically from the path, #108 (comment) .

I think I'm gonna add a command line option for that.

[ccchan234]

hi~
I am a new being and have a different view, not sure address the .diriv problem.

I made and backup-ed-many-times a single gocryptfs-folder, and give a name say "stock01".
that gocryptfs.conf (esp the masterkey, the random salts?) and the .diriv are kept safely.
This looks like a "container" say in truecrypt.

And this container "stock01" could be used for computer A and B as in the OP.

from that,
I tried that if you use beyond compare or whatelse to "sync" A's stock01 and B's stock01 at the root level,
the final folder should be readable.

I am using this as this is how I use:

unenc-data --> "stock01" --------> google drive

next time, when i modified unenc-data,
I will mount "stock01", sync into it.

then sync the encrypted-stock01 to google drive.

it should work that way, I gave some simple trials.

[ijjaz]

We have lost the filenames of a significant amount of data and cannot find the source of the issue with no way of providing debug information or a way to replicate this. Apologies for this but I'll try my best to explain what we used it for.

For compliance, we were using GoCryptFS to archive company data locally and mirrored this onto Google Team/Shared Drive. The last time this was done was in November 2018 and then we removed the data from our on-prem server.

After this date, we stopped using GoCryptFS and began storing data directly on Google. In February 2019 we needed some of the data and using GoCryptFS worked fine. The next time we tried to access the data was 1 week ago in 2020 and no files show up which I can only assume is an issue with the directory iv. The last time the files were modified, including the directory iv's, was in 2018 - the date the last backup occurred. No file has been modified since that date so we can't understand why it has stopped working.

However, now we have a need to encrypt data again and would like to start using this again but want to know how we can prevent this and if anything was done regarding #issuecomment-344848637 please?

[rfjakob]

Hi, it seems unlikely that you had a synchronization conflict on the diriv file - this can only happen when new empty directories with the same name are created at the same time at different hosts!

Can you show an ls -l on the encrypted directory?

[rfjakob]

This sounds like a wrong gocryptfs.conf is used, or that you are mounting using --masterkey (are you?)