# Tag Info

11

Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness. The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to ...

9

Yes, scrypt achieves this. Scrypt has a variable-length output, so just generate as much output as you need. For instance, you can ask it for 256 bits of output, then use the first 128 bits for one key and the second 128 bits for the other key. While PBKDF2 also has a variable-length output, I do not recommend that you use it in the same way. It has a ...

6

I've heard claims that it's relatively slow on Windows and/or Intel compared to Linux/AMD. The claim that it could be Windows/Linux is a little off. It is more likely to be Intel/AMD, if anything. This will be an implementation detail based on the relative costs of processor instructions on each architecture; for example inc instructions are cheap on ...

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

5

Both scrypt and pbkdf2 have variable length outputs, and each bit of the output is effectively independent on every other bit. So, one obvious way would be just to ask for enough output for both keys. For example, if the two keys are each 128 bits, then ask scrypt (or pbkdf2) for 256 bits of output; use the first 128 bits as the first key, and the second ...

4

I think linux thing is a case of "real programmers code and test under linux, then cross-compile", which results in a code that is far more tailored to linux systems. Intel processors (especially lower-end ones) tend to have a smaller L2 cache and if I read the scrypt paper right, that somewhat hobbles them. See comparison here ...

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

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

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

3

The scrypt function is specifically designed to hinder such attempts by raising the resource demands of the algorithm. Specifically, the algorithm is designed to use a large amount of memory compared to other password-based KDFs, making the size and the cost of a hardware implementation much more expensive, and therefore limiting the amount of paralleling ...

3

Non-malleability of Scrypt w.r.t. to salt (as well as passphrase) follows from the definition of Scrypt (which simply pass that salt to that input of PBKDF2); the definition of PBKDF2 (which uses the salt followed by a non-malleable encoding of an integer as a massage passed to HMAC_SHA256); the non-malleability of HMAC_SHA256 w.r.t. the message; and perhaps ...

3

No, you don't have to worry about collisions. As long as no pair of users have the same LowEntropy input, they will receive different MasterKeys. If the MasterKey is different, then the AuthKey will be different. Even if you use the same MasterKey to generate multiple AuthKeys, you don't need to worry about collisions: as long as the keynumber values are ...

3

If you have a high entropy input, then scrypt isn't a good choice. It's purpose is to compensate for the low entropy of a password. Don't ask the user for memory/cpu factors, you don't need them if the input is high entropy. You don't need a salt either. Simply use an input of at least 16 bytes from a secure random number generator. I recommend using one ...

3

Often I hear the key expansion is the weakest part of AES, but conflictingly that it was designed to prevent the use of "weak keys" which its precedent suffered from. The terms "weak" here mean different things. Some of the best attacks on AES have been oriented at attacking the key schedule. When these attacks were released the cryptographic community ...

2

The AES key schedule is firstly very fast, and build from a component (the s-box) that is used in the main encryption algorithm, too, so it can be implemented easily, sharing code (in software) or chip area (in hardware). I'm not sure how the AES key schedule avoids "weak keys" – I suppose this is meant to say that every AES key, when expanded, contains ...

2

Scrypt depends more on being a "Memory-Hard algorithm" as seen under section 2 here. PBKDF2 relies more on increasing CPU requirements by adding iterations. A good high level explanation of how KDFs like bcrypt/scrypt work is seen here. Also check out this explanation for a little more detail.

2

Salsa20 core is not a collision resistant hash function, see DJB's own webpage: http://cr.yp.to/salsa20.html For example, Salsa20core(x) = Salsa20core(x + c) for c = "0000000800000008...", thus demonstrating trivial collisions. To be concrete, try computing Salsa20core for the the following two inputs: 00000000000000000000000000000000 ...

2

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

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

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

1

Yes, Salsa20 core is not meant to be collision resistant. But that is not relevant to the intended use case of Scrypt: Password hashing. Password hashing is an unfortunate name, as "hashing" has so many specific meanings depending on the context. Two scenarios where you use password hashing are: Password storage for online services. Imagine your users log ...

1

IMHO it's just a warning to the reader that this is not a standard hash-based design like BSD-crypt or PBKDF2, which are traditional choices. They use the Salsa20/8 Core mixing function because its speed improves upon the first mixing function that was used in the defining paper for scrypt (that is referenced in the RFC you linked to): there he uses the ...

1

I believe scrypt is designed to be scaled to be both memory hard and cpu hard by explicit design. As a result, most implementations of scrypt will require you to input a desired cpu difficulty as well as a desired memory difficulty. On a gpu, where each core has very little memory, it would be trivial to see that, unless gpus gain a great deal of memory in ...

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