New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase the number of scrypt rounds #8193
Comments
Yes, it would be better if this were configurable (with 15 the minimum). Note that scrypt uses (1<<N)*2KiB memory, though, which is 2GiB at N=20. |
There will be some technical details to sort out in terms of making sure that the same setting is used among devices sharing a given folder etc. |
There's already a token passed around that needs to match - this might very well cause a failure already (with a then misleading message about mismatching passwords). |
The derivation only needs to be done on the sender's end. Large memory requirement is an explicit goal of scrypt, and An other solution would be to move to Argon2, winner of the PHC. |
I share @imsodin opinion. 2GB memory usage is an absolute dealbreaker IMHO. |
Not only that. I've worked in educational institutions and now help a friend with administering Syncthing at a school. Desktop computers with 2GB of RAM or even less are still very common there. Schools generally use computers until they break, and also due to constant financial constraints they tend to always go for low-end hardware even when buying new ones. |
I was wandering past and noticed your conversation ...
Please, do remember scrypt is a "defence in depth" or mitigation strategy. For it to have any effect the user has to have, at least, already chosen a poor password. In particular there is no way that the count could be considered "dangerously small" because it's reasonable to estimate it's "best world" effect is zero. But, because the "real world" isn't perfect, this is still a good thing to have, though the allowable cost (ie the number of rounds) is driven almost entirely by how much of a problem it is. Mostly, how long does a user on an expected client have to wait for the process to complete (not completing is bad!). So for the attached blog; the author uses their laptop as the expected device and the normal sub-second and five second delays for the patience of the user. Syncthing apparently has different requirements for these limits (eg "phones", "OldCrap" and "WeirdCrap") . PS: Argon2 series ... a quick skim reveals that this is really, really, new. The Alwen/Blocki attack is worrying, though as it only applies to the side-channel resistant variant this is probably not a severe issue as yet. Also you'd really need to check performance on ARM (etc) as it's supposed to be really slow for 32bit CPUs and other non-AMD64 machines. |
I was off by a factor of two: it's 1GiB, not 2GiB, for N=20. |
Argon2 - namely the argon2d and argon2id variants - is the new default for multiple password managers. I think we should follow here and replace scrypt. |
The current number of scrypt iterations used by syncthing is 32768, but this is the recommended value for interactive logins. As the security maintainer for go's crypto module said in his blogpost
from 2017:
and this was from 5 years ago, so 32k is dangerously small, so you might want to increase it, and maybe store it in the encrypted files' metadata, so that it can be modified in the future.
It would also make sense to stretch the passphrase before deriving it with
FolderID
: better to do an expensive computation once, then a couple of small ones than to do a lot of heavy ones.Something smarter than simply increasing the number of scrypt rounds would be to move to argon2id and put memory at 100-500MB.
Also, keeping in mind that syncthing is used on all kind of hardware, having the number of rounds settable by the end-user would solve the question of "how many rounds is the right amount of rounds".
The text was updated successfully, but these errors were encountered: