Tag Info

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

2

Probably because a simple cascade would only be stronger against some attacks, while opening the door to more implementation bugs. While bcrypt and scrypt are (password based) key-derivation functions, much of what is in the answers to this question about combining hash functions applies here. Different constructions give preimage resistance and PRF-ness, ...

2

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

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.

1

Some points towards an answer: Why HMAC-SHA3? HMAC and its security proofs have been devised for Merkle-Damgård hashes, and SHA3 is not one. HMAC-SHA256 would be fine (Updated per comment: the Keccak submission does endorse its use with HMAC, using a block size parameters of 576 (resp. 832, 1088, 1152) bits for the hash with output of 512 (resp 384, 256, ...

1

The way the iterations work is that it roughly increases your security (in bits) by $\log_2(iterations)$. So you would still need $\frac{\log{2}}{\log{97}}\cdot (256 - \log_2(10000)) \approx 37$ characters in your password to have 256-bits of security. Think of it this way, if you have $2^{256}$ possible keys, that is an astronomically large number. Much ...

1

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

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