gocryptfs.conf in cloud

[bugspencor]

As a follow-up to issue #37:

Is it safe to upload gocryptfs.conf into the cloud, if the password is strong enough?

If yes, how strong should the password be?

[rfjakob]

Yes. Let's do the math:

• Trying one password takes about 0.3 seconds on my PC. Let's say the attacker can check a million passwords per second.
• A random 16-character string of hex digits like "b5bb9d8014a0f9b1" has 16*4 = 64 bits of entropy. Brute-forcing this at 1 million passwords per second takes 290.000 years. Computed using Octave:

>> 2**64/1e6/3600/24/365/2
ans =    2.9247e+05

• So I'd go for 64 bits of entropy in the password. If you want to use the xkcd method, use six words instead of four, this will get you 66 bits.

[rfjakob]

Also very good is this tables that uses hardware cost as the metric instead: http://security.stackexchange.com/a/95764

We use scrypt with 0.3 seconds instead of 3.8. Also the table is from 2002, so lets say hardware has gotten 100x times cheaper since then, and we arrive at 1000x. So read from the bottom row and divide by 1000.

[xelra]

I guess what the OP wanted to ask is whether it's safer to keep the gocryptfs.conf local or whether this doesn't have any security implications at all, fully realizing that it's a lot more inconvenient to copy the configuration file on every client manually.

[rfjakob]

Yes, not uploading it is more secure.

[bugspencor]

Thanks for the answers!

So I will go for keeping the conf-files off-cloud.

[jerome-diver]

The next related question can be:

1. Why don't you (gocryptfs dev team) choose to put these files in other place ?

2. Is there a setup way for gocryptfs to let user happy to get the copy of these files inside a specific directory ? (for example: ~/.config/gocryptfs/$uniq_directory_name/)

I think it will be a great evolution.

[rfjakob]

Hi, you can put gocryptfs.conf wherever you like, and then use gocryptfs -config to use it. But this will not be the default, because gocryptfs should be easy to use and the encrypted folder should be self-contained.

[jerome-diver]

@rfjakob ok, thank you for the information about config file ability (could you develop or is it in the man page ?).
So the question linked to "safety first" become:
Do you think it can be possible to be easy to use and increase safety by not put .diriv and .conf file inside the self-contained encrypted folder ?
My proposition to increase safety without sacrifice usability is:
Put them together inside the non encrypted folder by default should be the easy and safe way to go with. This way, you should aprouve it stay easy and become safe.

Do you agree ?

[impredicative]

As per this comment, it is okay to backup gocryptfs.conf (as a part of the crypt folder) if and only if the password is strong.

[eugenesvk]

use gocryptfs -config to use it.

that's not as seamless as having already some kind of XDG_CONFIG var defined for other purposes and having gocryptfs understand it without any extra flags (in case it doesn't find any config files in the encrypted folder)

[Eirikr70]

In case you loose your gocryptfs.conf file, can you still read your files with the password and/or the key ?

[rfjakob]

With the masterkey yes. Password without the conf file is useless.

…

On Wed, 14 Feb 2024, 09:14 Eirikr70, ***@***.***> wrote: In case you loose your gocryptfs.conf file, can you still read your files with the password and/or the key ? — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA77L2RDJZ4T5JTO2NFTYTRW5TAVCNFSM4CTIWL22U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJUGMZDMNBVGY3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>