Entropy of untrusted device scrypt salt

Congrats on getting on HN front page.

One user raised an interesting question w.r.t. entropy of salt in scrypt key derivation. I don’t know the answer, but I think they’re right, and in the past I’ve used random salt in my projects.

The folder ID can be set by the user so there are no guarantees. However, in most cases everyone uses our auto-suggested random folder IDs. Those are ten characters, with a character set that has about 5.8 bits of entropy per character, so about 58 bits. We do this because we need the property that keys generated for the same folder on two different devices need to be the same, without them pre-communicating about it, or they cannot exchange encrypted data. Hence we cannot pick something entirely random, it needs to be somehow a property of the folder itself.

There are some other minor issues with the encryption scheme (too few scrypt rounds to be ideal, suboptimal file name structure) so we should probably do a version two at some point. A complication is doing it so that it doesn’t impact existing setups.

1 Like

Is it unsafe less safe to share the “Default Folder” as encrypted then? Its folder ID is always just default.

In the sense that someone could easier pre-brute-force all passwords for that specific folder ID, yes. If your password is reasonably brute force resistant, then no. So “unsafe” is a strong word in the context, imho.

Sorry for that, changed to “less safe” then. If the passwords are randomly generated and have very high entropy, then there should be not much to worry regardless of the folder ID, right?

That’s my understanding.