Salt reuse in directory encryption

[sh-dv]

I had so much fun going through the updated kryptor documentations once again, I must congratulate you for the work you have put into writing them. I have came across the directory encryption known limitations, where it's mentioned that in the upcoming v4, this limitation will be gone due to the planned work around of zipping the file, Where you end up with one file that gets encrypted like a regular single file.

I think this definitely solves the limitation. However, it opens up few more, Like you have said, you have to figure out if the file is a zipped directory in order to unzip it after decryption. And you have to implement zipping and all that jazz. Users will be limited to always decrypt the whole directory even if they intend to only decrypt one file. And the "one file" idea kind of can be done in v3 if the users zips a directory then encrypts it.

Decrypting a whole directory requires the presence of a kryptor.salt file. Meaning, having to rely on the user keeping that file intact in order for future directory decryption, unless they decrypt each file manually. In addition, new users may go encrypt a directory and be surprised by this extra file and go delete it without knowing it's importance.

I think in Kryptor the encrypted directory salt file can be avoided by repeating the EncryptInputFile() function for all the files in a directory with new salt for each file, this can be done by creating two variables : totalFilesCount currentFileCount, and after each file encrypted you increment the currentFileCount variable and repeat the EncryptInputFile() again. If both variables are equal you display the DirectoryEncryptionComplete. OR you just make a new salt in the EncryptInputFile func instead of passing the salt from UsingPassword to EncryptEachFileWithPassword to EncryptInputFile

If you want to keep the directory still encrypted with the same salt, you can manage decrypting all the files without having the salt file there : Since the user already intended to decrypt a whole directory, you can get the FileHeaders.ReadSalt(inputFile) just from one file, and this salt applies to all files since it's an encrypted directory. But still this doesn't solve the reused salt.

I hope you got my point. Regard, sh-dv.

[samuel-lucas6]

Thanks @sh-dv. I'm still in the process of updating parts of it :)

The directory encryption situation is indeed a tricky one, and I'm still not sure what the best solution is.

Like you have said, you have to figure out if the file is a zipped directory in order to unzip it after decryption. And you have to implement zipping and all that jazz.

That can be solved by having an encrypted boolean file header that indicates whether the encrypted file is a file or directory. The ZIP handling shouldn't be a problem after that besides a performance limitation, although it would mean Kryptor wouldn't have to back up the original directory if -o|--overwrite wasn't specified.

Users will be limited to always decrypt the whole directory even if they intend to only decrypt one file. And the "one file" idea kind of can be done in v3 if the users zips a directory then encrypts it.

That's exactly why I didn't do it this way in the first place, and that's true. However, from a user perspective, Cryptomator works in this fashion. The usefulness of being able to decrypt an individual file really depends on whether file name encryption was used.

Decrypting a whole directory requires the presence of a kryptor.salt file. Meaning, having to rely on the user keeping that file intact in order for future directory decryption, unless they decrypt each file manually. In addition, new users may go encrypt a directory and be surprised by this extra file and go delete it without knowing it's importance.

The other annoyance is that files have to be created and encrypted to store the directory names if file name encryption is used. This leads to confusing output in the terminal because random files are getting encrypted. It's also an issue if the user renames a directory because then the directory name won't be restored.

Performing name encryption like Cryptomator does would be a nightmare as it would limit the maximum length of names and prevent renaming for encrypted files as well. Instead, treating a directory as a single encrypted file solves these problems.

I think in Kryptor the encrypted directory salt file can be avoided by repeating the EncryptInputFile() function for all the files in a directory with new salt for each file, this can be done by creating two variables : totalFilesCount currentFileCount, and after each file encrypted you increment the currentFileCount variable and repeat the EncryptInputFile() again. If both variables are equal you display the DirectoryEncryptionComplete. OR you just make a new salt in the EncryptInputFile func instead of passing the salt from UsingPassword to EncryptEachFileWithPassword to EncryptInputFile

I believe you're describing what I was doing prior to v3. Instead of deriving one KEK for a directory and all subdirectories, I was deriving a new key for each file, which slowed down directory encryption significantly because there was a ~1 second delay per file. That's why I switched to just deriving one key. However, with asymmetric keys, a new is derived for each file.

If you want to keep the directory still encrypted with the same salt, you can manage decrypting all the files without having the salt file there : Since the user already intended to decrypt a whole directory, you can get the FileHeaders.ReadSalt(inputFile) just from one file, and this salt applies to all files since it's an encrypted directory. But still this doesn't solve the reused salt.

That's true assuming all the files have the same salt, but then there would be no way of differentiating between a password encrypted directory and a private key encrypted directory, which could lead to lots of unhelpful errors instead of just one helpful error.

[sh-dv]

Thanks for the clarification, I got the full picture now. How important is it to preserve the name of the directory ? If you don't store directory names the salt reuse can be avoided, true?

It's also an issue if the user renames a directory because then the directory name won't be restored.

I now can understand your point.

I don't know if I am doing this correctly, but what if you do the following :

Directory Encryption with name encryption:

1. Create a text file with the name kryptor_dirname, that contains the directory name inside, then encrypt this file with the password input. and encrypt the file name too.
2. Create a new folder with random name.
3. Encrypt all the desired files with the password, store their original name as you do, without storing directory name. no salt reuse.
4. After each file is encrypted, Move it to the folder created in step 2, which already has the encrypted text file that contains the dir name.
5. Proceed to the next dir/subdir and repeat.

Directory Decryption with restoring encrypted directory and file names:

1. Create new folder with random temporary name.
2. Start decryption of the files in this directory. After all files are encrypted in that path, check which file matches with the name kryptor_dirname. Copy the contents of that text file (which should be the upper directory name), then rename the directory created in step 1 with the copied name.
3. Remove the kryptor_dirname file.
4. Proceed to the next directory or sub directory and repeat.

If step 2 fails to identify a file named kryptor_dirname, then continue decryption of the files and change the folder name to "Decrypted files" instead of the original dir name because the user has deleted the extra file that contains the dirname.

This should be tricky and I may be wrong, please let me know.

[samuel-lucas6]

Thanks for the clarification, I got the full picture now. How important is it to preserve the name of the directory ? If you don't store directory names the salt reuse can be avoided, true?

Very important, and that's incorrect, I'm afraid, as using one salt is to avoid Argon2 delays, not because of the name encryption. The issue at play is that you cannot derive multiple keys using a password-based KDF without a substantial delay. You either:

1. Derive one key using one salt to get the minimum delay
2. Derive a key per file using a unique salt per file but get the maximum delay, rendering the directory encryption horribly slow.

Cryptomator essentially does what Kryptor is doing but in a more complicated manner due to their name encryption approach. There's a masterkey.cryptomator file that contains a single random salt for the entire vault. That means they only perform password-based key derivation once, and they use much smaller parameters than Kryptor, making that faster.

[samuel-lucas6]

@sh-dv As an update, my current plan is to go ahead with this ZIP file idea but avoid using compression because a) it's generally a bad idea to Compress-then-Encrypt and b) compressing directories would be significantly slower. Then I can implement an encrypted boolean header to distinguish between a file and directory, as I said before. The file name encryption will also move to an encrypted header.

Boosting the file encryption/decryption performance will hopefully help render the decrypting the whole directory issue rather moot. The current performance is all right, but it can definitely be improved, perhaps using something like memory-mapped files. Otherwise, doing this comes with loads of advantages, like preventing encryption of a directory completely if a file has already been encrypted or the file name contains invalid characters when -n|--names has been specified.

[samuel-lucas6]

Afraid not at present. I haven't started working on this at all yet. There are some other things I'll probably implement first before getting to these larger changes, and I need to sort out some other projects first, such as the Geralt libsodium binding. I'll let you know if I do any.

[sh-dv]

Sure!! please let me know when you have some results, because it's something that i thought about lately (1 salt for directory and performance), Because if there was a workaround for this, I think it could be really useful to code a more secure and efficient clone of cryptomator.. (?)

[samuel-lucas6]

I expect the delay creating the ZIP will make it slower than encrypting individual files no matter what, but it'll be a lot easier to handle than their overcomplicated name encryption and directory structures, and hiding more metadata is almost always a good thing.

[sh-dv]

Is this going to be ZIP-then-Encrypt ? or Zipping and encryption happens simultaneously?

[samuel-lucas6]

ZIP-then-Encrypt because I don't think simultaneously is possible.