# Tag Info

5

All looks pretty secure except for your auth key derivation. You should use a better key derivation method like HKDF instead of just SHA-512. I don't think your random nonce is doing anything in this scenario - an attacker who wants to brute-force a weak password wouldn't be slowed down by a nonce transmitted in the clear. Why not just use a ...

4

The operation: X[16] & (N-1) is really, mathematically speaking: $$X[16] \mathrm{\ mod\ } N$$ With a generic $N$, this operation must be done with an actual division, which is expensive; some CPU types don't provide it, and for CPU which do provide it (e.g. x86), it is quite slow (for instance, for 32-bit operands on an Intel Core2, division latency ...

4

The threat model of password storage is that of server compromision, where the attacker gain access to the database and server code. The attacker can then run the code to test password candidates, possibly making modifications, porting to faster platform, etc. The attacker will not bother computing the fake hash and fake salt. So this scheme is twice as ...

4

Scrypt is most certainly a password-based-key-derivation-function. So is PBKDF2, although it can be confusing since PBKDF2 is an eponym. To add to the confusion, Scrypt uses PBKDF2 internally (which may be the hashing function you refer to), as well as the Salsa20/8 Core function (which may be the encryption function you refer to). Further reading here.

3

Salsa20/8 is used not to enhance cryptographic strength, but to make random-ordered requests to the RAM (and to slower FPGA/ASIC implementation of scrypt). The scrypt uses PBKDF2-HMAC-SHA-256 (PBKDF2 of HMAC-SHA256) to provide such strength. There is simple variant of scrypt, with parameters p=1 (Parallelization parameter), N=16384, r=8, taken from linked ...

3

Can formulae for equivalent year cost be constructed to determine the parameters as functions of time since those tests were performed? Yes, but you have to make a lot of assumptions. First, though, note that the paper says: We caution again that these values are very approximate [...] Nevertheless, we believe that the estimates presented here are ...

3

The #1 thing you can do is: don't derive your keys as a function of a password/passphrase. That's a security breach just waiting to happen. Using something like scrypt mitigates the risk somewhat, but by no means does it eliminate the risk. This is likely to be the weakest link in your cryptographic scheme. Instead, use a truly random value as your ...

2

No, scrypt in not vulnerable to password extension attacks. Internally, scrypt passes the password to PBKDF2, which uses it as a key for the HMAC function -- hence they've effectively already done the workaround you thought of.

2

I would advise against this. When implementing slow-hashing (such as bcrypt or scrypt), it's usually recommended to select as high a work-factor as is tolerable (in relation to how much time the user is willing to wait, and/or how much strain you're willing to put on your server). Assuming you're working within this constraint, using two distinct slow ...

2

scrypt uses PBKDF2 internally, so it's absolutely crucial to prevent nasty interactions. My suggestion would be a simpler scheme (using simplified syntax): $k = \mathrm{scrypt}(key, salt || 0x0) \oplus \mathrm{PBKDF2}(key, salt || 0x1)$ This does exactly what you want - that is, the output key has exactly the strength of the stronger of the two, without ...

2

PBKDF2 and scrypt are both password based key derivation functions (PBKDF's). scrypt is different in the fact that it has a large internal state. This means that it is hard to create a hardware accelerator for it. This means that an attacker cannot use a hardware implementation to gain advantage over the legitimate user. For more information, please see the ...

2

If you use a potentially guessable username as the salt, you should add a global salt that no other services or programs will be likely to use for scrypt. For example, a long random number. That ensures that attacking another user database does not simultaneously allow attacking your users' hashes. However, if two users are allowed to choose the same ...

1

Using the user's username as the salt is not totally unreasonable -- but there is usually no reason to do it. If you can store the password hash, you can usually also generate and store a truly random salt. And using a truly random salt is more reliable than counting on the user to select a random username. Using the username as the salt does have some ...

1

The developers claim that a 6 letter long password hashed with 3.8 seconds of scrypt would cost \$900 to brute-force. Very important: This is the cost of finding the password within a year by building an ASIC in 2002. Not so important: There seems to be only one person behind scrypt: Colin Percival. If we use more cycles, how quickly will the brute ...

1

You have to test it on the hardware you'll be using. I tried CryptSharp's implementation with a cost of 262144 and it took about 7 seconds. The reason it costs more is cause of the memory it uses, and my process that was running the Scrypt was eating up 340ish MB. How much of that was from the KDF? Don't know. How would my box handle 100 people ...

1

Mostly similar questions than this are about scrypt and PBKDF2. Shortly: No. The execution time for slow-hashing (password-based key derivation) must be as long as you can afford (i.e. as long as your users are willing to wait for password derivation). If you use two functions, one taking another as input the time will normally grow, and you get less ...

1

Deﬁnition 4: The key derivation function scrypt is deﬁned as scrypt(P, S, N, r, p, dkLen) = MFcryptHMAC SHA256,SMixr(P, S, N, p, dkLen) The limits on the size of p and dkLen exist as a result of a corresponding limit on the length of key produced by PBKDF. Users of scrypt can tune the parameters N, r, and p according to the amount of memory ...

Only top voted, non community-wiki answers of a minimum length are eligible