Skip to content

[docs]: scrypt use correct units and fix interactive login usage #41

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[docs]: scrypt use correct units and fix interactive login usage #41

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions mac-and-key-derivation/scrypt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,13 +25,13 @@ The **memory** in Scrypt is accessed in strongly **dependent order** at each ste
Memory required = 128 * N * r * p bytes
```

Example: e.g. 128 \* N \* r \* p = 128 \* 16384 \* 8 \* 1 = 16 MB
\(or 128 \* N \* r \* p = 128 \* 2048 \* 8 \* 1 = 2 MB\)
Example: e.g. 128 \* N \* r \* p = 128 \* 16384 \* 8 \* 1 = 16 MiB
\(or 128 \* N \* r \* p = 128 \* 2048 \* 8 \* 1 = 2 MiB\)

**Choosing parameters** depends on how much you want to wait and what level of security \(password cracking resistance\) do you want to achieve:

* Sample parameters for **interactive login**: N=16384, r=8, p=1 \(RAM = 2 MB\). For interactive login you most probably do not want to wait more than a 0.5 seconds, so the computations should be very slow. Also at the server side, it is usual that many users can login in the same time, so slow Scrypt computation will slow down the entire system.
* Sample parameters for **file encryption**: N=1048576, r=8, p=1 \(RAM = 1 GB\). When you encrypt your hard drive, you will unlock the encrypted data in rare cases, usually not more than 2-3 times per day, so you may want to wait for 2-3 seconds to increase the security.
* Sample parameters for **interactive login**: N=16384, r=8, p=1 \(RAM = 16 MiB\). For interactive login you most probably do not want to wait more than a 0.5 seconds, so the computations should be very slow. Also at the server side, it is usual that many users can login in the same time, so slow Scrypt computation will slow down the entire system.
* Sample parameters for **file encryption**: N=1048576, r=8, p=1 \(RAM = 1 GiB\). When you encrypt your hard drive, you will unlock the encrypted data in rare cases, usually not more than 2-3 times per day, so you may want to wait for 2-3 seconds to increase the security.

You can perform tests and choose the Scrypt parameters yourself during the design and development of your app or system. Always try to use the **fastest possible implementation of Scrypt** for your language and platform, because crackers will definitely use it. Some implementations \(e.g. in Python\) may be 100 times slower than the fastest ones!

Expand Down