[Sprite_tm]

Am I the only one a bit worried about them using a fixed string as a salt? A salt is intended to make it hard to create a rainbow table. I don't know how much entropy is in their 'folderID' variable, but given that it's a 'short string', it seems low-entropy and not random. If so, the current implementation makes it trivial to make a rainbow table. That means that if you can get the passwordtoken and know a folderID, you can create a rainbow table that maps all possible passwordtokens to valid passwords.

BTW: 'worried' as in 'code smell', not 'worried' as in 'the encryption can be easily broken'.

[h4kor]

> The string “syncthing” with the folder ID concatenated make up the salt

Meaning its not fixed but every folder has its own salt

[halJordan]

The question is how trivial is it to get the folder id. If it's just an incrementing integer, is it really providing a good salt? Im not actually asking that question or asserting that it isnt, just explaining what you missed.

[dpc_01234]

I think you're right. Reported on Syncthing forum. https://forum.syncthing.net/t/entropy-of-untrusted-device-sc...

[scoot]

>> Is it 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.

That's the definition of a rainbow table, and a fixed, known folder ID makes the "salt" effectively worthless.

[sneak]

the folder ID is a (from memory) 6 character random alnum string.

this is more than adequate for a salt.

[notfed]

That would mean each salt is about 36 bits. If you create 2^18=262k folders in your lifetime using the same algorithm and same password, there's a 50% chance one of the salts is dup'd.

Maybe we can wave this as good enough, but cryptography usually has higher standards.

[sneak]

These don’t refer to individual directories, only top level syncthing folders. Nobody in their lifetime is making even 1000 of these.