feature request: obfuscated file names

[sudomain]

Problem: encrypted files in a blackbox repo can have reveal metadata about the contents of the file e.g. Pictures/Screenshot_2021-05-12-15-16-04.png.gpg. Sure the user could rename the files to something non-descript before encrypting, but I think there's a better solution:

Proposed solution: rename files to something non-descript yet unique, such as a hash, and store a mapping of hashed file name -> real file name in a new (encrypted) config file. Another command will decrypt this fileand create temporary symbolic links with the real file names to the hashed file names.

2 new commands:

1. blackbox_obfuscate_paths FILES which will rename the given FILES to something non-descript yet unique. Perhaps a hash of the relative path to a file? Also, if symbolic links were previously created with blackbox_unobfuscate_paths (see next paragraph), then obfuscate_paths will delete the links.

2. blackbox_unobfuscate_paths which will create temporary symbolic links to the obfuscated files. The names of these links will be the name of the original files before obfuscating their names.

other implementation ideas:
.gitignore symbolic links

blackbox_obfuscate_paths will create and append to a new blackbox config file blackbox_paths.txt.gpg which will contain null-separated entries of mappings from the obfuscated paths to the unobfuscated file names. This file will be encrypted at rest and will be used by blackbox_unobfuscate_paths to create the symbolic links

[Tom Limoncelli]

Wow! That's quite a an interesting feature.

Matt Blaze addressed that problem in 1993 when he wrote CFS (https://www.mattblaze.org/software/). It isn't an easy problem to solve. For example, shouldn't the blackbox_unobfuscate_paths file be encrypted too? Seems very complex.

Sadly, my goal is to keep blackbox very simple. It is just a wrapper around "gpg --decrypt". Blackbox doesn't try to solve problems that gpg doesn't solve. It is better to create a new layer on top of BB rather than trying to make BB do everything.

That's a very long winded way of saying I don't think this feature is right for BB.

However I do have one suggestion: How about encrypt the files using obfuscated names and provide a layer that creates symlinks using the "normal" name pointing to the obfuscated name? You could have a text file of "real -> obfuscated" names and a script that creates or updates the symlinks.

Tom

[sudomain]

Thank you Tom for the detailed response. I totally understand that it's not something for BB. Therefor it'll be a separate project to tack onto my todo list, probably utilizing githooks

The (un)obfuscated_paths.txt (or whatever it would be called) file would indeed be encrypted since it would contain the real paths that we're trying to hide. You're right that it would make more sense to have that file contain real -> obfuscated instead of obfuscated -> real like I suggested.

Thanks for your work on BB.