gocryptfs.diriv in cloud

[emreuenal]

Hi, thanks for your work.

is it safe if i upload my encrypted directory with the gocryptfs.diriv file to my cloud (Dropbox, ACD ect.)?

[rfjakob]

Yes it is, the diriv files are not secret!

[emreuenal]

thx for the quick response

[bolle732]

I would prefer to remove the "gocryptfs" part of the "gocryptfs.diriv" files to hide the used tool. Or is it plain simple to determine the used tool from the data in the encrypted folder?

I know, this is security by obscurity. But the less information one can get directly from the encrypted data, the better I feel ;-)

[rfjakob]

I'm sure it's possible to identify it from the file content (for example, there is a two-byte version header in every file, currently 0x0002). But it does take more work and skill to do it.

I don't think I will want to add a command-line option for that, but if you don't mind compiling yourself, it's just the DirIVFilename constant in diriv.go:
https://github.com/rfjakob/gocryptfs/blob/master/internal/nametransform/diriv.go#L20
Contact me should anything break.

[bolle732]

Thanks a lot for the reply. Yes, I could change the constant and compile it my self. But I do that mostly for test cases and normally try to go with the standard packages from the distributions (my Gentoo time is about 15 years ago).

Using only ".diriv" would have another neat effect to have this special file better separated from the encrypted content. Especially with raw64, there won't be other files or folders starting with a dot.

[rfjakob]

Yes, the dot in the file name makes sure there are no collisions with encrypted files (this is also true for gocryptfs.diriv, where the dot is in the middle).

I though about calling the file just .diriv. The thing is, dot files are hidden by default, and users may miss the file when they take a backup of their encrypted files.

[bolle732]

It's true regarding hidden dot files could be a problem for inexperienced users. But they are widely used in Unix for other files which needs to be backed up.

Therefore, an explicit options to use .diriv could be a viable solution.

[bolle732]

If the file name for the diriv is specified at the init phase, it could be stored in the conf file. Defaulting to gocryptfs.diriv would keep backward compatibility.

[bolle732]

OK, compiled by myself. Had to change some occurrences in fs_dir.go too (tmpName). Seems to work and I'll do more tests so I can replace my EncFS fodlers. Thanks for your help.

[dm4g3]

Sorry for bumping old topic, but...
Is there any chance for change this file name to dot diriv ?
Also, why pattern of filename couldnt be placed into gocryptfs.conf file?

[rfjakob]

So the goal is to somewhat hide that gocryptfs is used, right? Wouldn't it be best to use a "random crap" filename like asd3Etsdg4t2.nszhe5X ?

[dm4g3]

I would say not to completely hide, but at least it wouldn't be obviously from the first look.
It would be better to have an option to set this filename to "random crap" (you mean filename will be different in every directory, right?), because it may look weird, when you have a one "randomcrap" little file in each directory and no other files (in some other directories).
And when you have just dot file like a folder.ico or thumbnail.jpg or something like that, it looks okay.

[db-inf]

Just two thoughts, both valid only when using encoded filenames.

1. Encoded files can be recognised by the string length of their encoded file name (21 bytes for the shortest, 43 for longer names, etc., so probably some base64 encoded result of encryption to 16-byte long blocks). So any filename with a different length would set it apart as this is not an encoded file, but a gocryptfs special file
2. The diriv file is only 16 bytes long. Why use a separate file for that? These 16 bytes base64-encoded to 21 chars can be added to the directory name itself, as prefix or suffix, eventually separated by a dot to provide for a future change of IV length. For the base directory the IV could be added to the gocryptsfs.conf file.