Skip to content
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

Open
jvoisin opened this issue Feb 25, 2022 · 10 comments
Open

Increase the number of scrypt rounds #8193

jvoisin opened this issue Feb 25, 2022 · 10 comments
Labels
bug A problem with current functionality, as opposed to missing functionality (enhancement)

Comments

@jvoisin
Copy link

jvoisin commented Feb 25, 2022

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
:

    interactive logins: 2^15 — 1 << 15 — 32 768 — 86ms
    file encryption: 2^20 — 1 << 20 — 1 048 576 — 3802ms

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".

@jvoisin jvoisin added bug A problem with current functionality, as opposed to missing functionality (enhancement) needs-triage New issues needed to be validated labels Feb 25, 2022
@greatroar
Copy link
Contributor

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.

@calmh
Copy link
Member

calmh commented Feb 28, 2022

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.

@calmh calmh removed the needs-triage New issues needed to be validated label Feb 28, 2022
@imsodin
Copy link
Member

imsodin commented Feb 28, 2022

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).
Also 2G? o.O All those old phone and other micro-device users will be furious.

@jvoisin
Copy link
Author

jvoisin commented Feb 28, 2022

The derivation only needs to be done on the sender's end. Large memory requirement is an explicit goal of scrypt, and 1<<15 (aka 86ms 5 years ago) is really low :/

An other solution would be to move to Argon2, winner of the PHC.

@bt90
Copy link
Contributor

bt90 commented Feb 28, 2022

I share @imsodin opinion. 2GB memory usage is an absolute dealbreaker IMHO.

@tomasz1986
Copy link
Contributor

Also 2G? o.O All those old phone and other micro-device users will be furious.

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.

@rdebath
Copy link

rdebath commented Mar 3, 2022

I was wandering past and noticed your conversation ...

Also 2G? o.O All those old phone and other micro-device users will be furious.
... Desktop computers with 2GB of RAM or even less ...

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.

@greatroar
Copy link
Contributor

I was off by a factor of two: it's 1GiB, not 2GiB, for N=20.

@calmh
Copy link
Member

calmh commented Oct 11, 2022

@bt90
Copy link
Contributor

bt90 commented Jun 22, 2023

Argon2 - namely the argon2d and argon2id variants - is the new default for multiple password managers. I think we should follow here and replace scrypt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A problem with current functionality, as opposed to missing functionality (enhancement)
Projects
None yet
Development

No branches or pull requests

7 participants