File name encryption?

[Zerqz]

Steps to reproduce

1. enable Default encryption module 1.6.0
2. test to see that a .txt file has been encrypted

Expected behaviour

The contents of the file are encrypted, and it's name is obfuscated / encrypted

Actual behaviour

The contents of the file is encrypted, but its name is not.

Server configuration

Operating system: Ubuntu server 17.04

Web server: apache

Database: MariaDB

PHP version: 7

Nextcloud version: (see Nextcloud admin page) 12

Updated from an older Nextcloud/ownCloud or fresh install: fresh

Where did you install Nextcloud from: nextcloud.com/downloads

Signing status: https / lets encrypt

I haven't been able to find any documentation on this matter, but it would be very helpful is file name encryption was an included feature with the default encryption module. 

Is there as way to enable this?

[schiessle]

No, the default encryption module only encrypts content, not the file name. The main reasons:

1. really encrypt the file names would be a huge performance issue if you enter a folder with many files and the server needs to decrypt every single filename in order to show the file listing
2. If you want to avoid the 1. you can't encrypt the file name but just obfuscate it, with a mapping in the database. This doesn't add a lot of security since everyone with access to the system could lookup the real names but would add a lot of overhead and potential sources of error.

That's why we decided against it. Of course thanks to the modularity everybody is welcome to write their own encryption module which also encrypts file names.

[kiplingw]

+1

[KimTheFirst]

I'd like to bump this issue as it seems like a good feature to have and I believe that there is an alternative way of approaching the problem besides what has already been mentioned by @schiessle.

If one were to implement some kind of indexing then this would effectively eliminate both of the stated issues. I propose something like this:

• An index encrypted with the same keys as the filesystem would map filenames and file attributes to the encrypted filenames.

• In the event that the index is lost, it can be rebuilt as long as the keys are retained.

• The index can be a separate database table, .index files on the filesystem itself, sqlite, etc.

• The index would be limited in scope to performing filename searches.

• In the event that the user is highly paranoid, obfuscation of the directory structure itself can be implemented with file padding, path obfuscation, random file generation, etc. This is beyond the scope of what I am proposing, but I thought it was worth mentioning whilst I had it on my mind.

There is little risk of data loss beyond what already exists with filesystem encryption. Furthermore, there may be significant scope for performance improvements over the regular filesystem particularly in regards to external storages.

I believe that https://github.com/nextcloud/fulltextsearch/ already provides an encrypted at rest search index; this in and of itself is not suitable for what I am proposing as filename indexing has a much narrower scope, but there may be at least some common scope. Fulltextsearch also requires a third party indexing app, whereas I believe that what I am envisioning should work on a vanilla server. I would be interested in hearing whether or not @cult has an opinion on this.

As I am proposing to make this interoperable with the existing filesystem encryption, is an external module the best way to go? I think that it would be best to have it integrated within the encryption module itself due to the fact that data integrity issues will be more likely to arise if the two are not tested extensively as a single unit.

Imagine the scenario where due to staggered updates of two separate filename encryption and filesystem encryption systems, one of the two fails to function. Or imagine that at some point in the future, one of the two changes it's encryption method leaving the filenames encrypted with one standard and the files encrypted with another. Or imagine that data is re encrypted with another key and the filenames are not. It is probably the case that this kind of error could be made highly unlikely with appropriate safeguards, but because the potential consequences of this type of error would be quite high (ie massive data loss) it does demand attention.

This is just my opinion - I'd be interested in hearing opinions on this from anyone more experienced with the NC file system.

[KimTheFirst]

If one uses the NC encrypted filesystem to store indexes as regular files with the encryption being transparent to the filename module, this would mitigate the above mentioned problem. In the event that the filename module becomes inoperable then the indexes can be recovered by just reading the mappings out of the index file.

This does limit the options a bit; in my opinion it might still work better as a single module.

[ghost]

I agree that this should be at least an optional feature. Even if the performance is affected, I'm sure many people wouldn't mind devoting the necessary resources for it. Encrypting files and folders is only a partial security measure when their names themselves can already tell much about them, and it also points attackers to the specific place they should target.

[alekseyp]

I agree that file names should be obfuscated. Especially if you are using external storage. Adding name obfuscation / encryption would allow me to use external storage without concerns that people can read file names, which on it's own is a huge flaw. For example bank statements would include account names, credit card numbers, etc in it's names.

[FakeEmperor]

Could we reopen this? I've looked into the standard encryption module. Is it safe to assume that the only logic related to encrypting actual files resides here? https://github.com/nextcloud/server/blob/master/apps/encryption/lib/Crypto/EncryptAll.php#L294. If that's so, it's fairly easy to implement and I can prepare a PR in some time (with "some time" varying from 2 weeks to 2 months :/). I'm envisioning this process:

• We'll add another option in the module to allow encryption of filenames;
• During encryption of a file, we'll check if a user has decided to encrypt filenames, and if so, continue;
• Encrypt the filename;
• Include the original filename in file's header;
• Include in the encrypted index file.

Decryption process is easier:

• Check for the index file;
• If present, decrypt the index;
• Obtain original filename from encrypted one;

This implies that filenames would be eventually consistent :) as there is a chance of mismatching filenames in index and file's encrypted header. And if the index file is somehow corrupt, filenames will be hot garbage, that's true. But once the user opens up a file, we'll decrypt the filename along file's contents and can restore the filename fairly easy, updating filename in index. So the restoration process, if we'll do literally nothing else to support restoration, would be to download all affected files -- during decryption process we'll restore filenames.

Whenever user disables this option, we could always restore the original filenames as we'll decrypt files when we're showing contents to the user.

Nevertheless, I see a few other problems:

• Renaming a file would mean re-encryption (or re-encryption of at least the header part);
• There might be some potential issues with accessing files as technically those files aren't there as their names changed;
• It is indeed a bit costly operation;

Even with these restrictions, I think there is enough interest in this feature to include in the standard module. Oh, we might also want to add a list of glob masks relative to the data root that enable this behavior. Other than that, I think it's fairly straightforward to do :)

[aitorpazos]

Sorry for reiterating on this, but this is a big blocker to use Nextcloud together with external storage, so I kindly ask to re-open this issue. You may argue that using external storage weakens your privacy position already. However, the burden of scaling and managing storage is significant. As a user I want to run my own Nextcloud installation, so I keep control on the DB and the server (including encryption keys and so on), but I acknowledge that managing and scaling storage is hard, so I am willing to pay third parties to do it for me and use the external storage functionality to link plug into them. However, that doesn't mean I trust them and therefore I am not comfortable giving them the names of all my files.

[Kuphi]

If that's so, it's fairly easy to implement and I can prepare a PR in some time (with "some time" varying from 2 weeks to 2 months :/). I'm envisioning this process:

I would like to see this feature implemented. File and folder name obfuscation is a key feature of encryption in cloud storage. How can I contribute by providing a bounty for this function?

[AyupMike]

+1

[nokaka]

+1

[mikeperalta1]

+1

[LucasElbert]

+1

[ner00]

+1

[hendricksond]

When a file name can include personally identifiable information, it is very important to be able to encrypt that filename when using external storage, at least as an option for users who need that functionality. @schiessle please consider re-opening this issue.