25
$\begingroup$

After reading these two resources I am wondering am I getting all the differences between Scrypt and PBKDF2.

As far as I understood, the similarity is:

  • both are password-based key derivation functions.

The difference is:

  • Scrypt is more resource demanding.

Am I missing something?

$\endgroup$
1

2 Answers 2

40
$\begingroup$

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 make cracking it harder to parallelize using devices like GPGPUs or custom ASIC / FPGA hardware. Such devices may have hundreds or even thousands of parallel processing units, each capable of hashing a different password using traditional KDFs like PBKDF2, which don't require much memory. However, it turns out that, at least using current technology, providing each of these parallel units with large amounts of memory space is a lot more difficult and expensive than making the units themselves.


Another difference between PBKDF2 and scrypt is that PBKDF2 is a generic construction for turning any cryptographic hash function (actually, a pseudorandom function, but the most common way to obtain a PRF for PBKDF2 is to build one out of a hash function using the HMAC construction) into a key-stretching KDF. Thus, the actual KDF you use might be e.g. PBFKD2-HMAC-SHA256, meaning PBKDF2 built on HMAC built on the SHA-256 hash function.

Scrypt, on the other hand, is a specific key derivation function with "no user-replaceable parts inside". While scrypt does make use of some standard functions and constructions (in fact, it internally uses PBKDF2-HMAC-SHA256 for the state expansion and compression stages), the scrypt specification doesn't make any allowances for, say, changing the hash function to something other than SHA-256. It's a "take it or leave it" deal.

That said, it would, in principle, be possible to define a new KDF using the priciples described in the scrypt paper, but with different components. In particular, the scrypt paper defines scrypt as an instance of a more general construction called MFcrypt, instantiated with HMAC-SHA256 and the memory-hard mixing function SMix (also defined in the paper). It would be possible to use an MFcrypt instance with, say, SHA-3 instead of SHA-256, but that function would no longer be "scrypt" as defined in the paper.

$\endgroup$
3
  • $\begingroup$ I'm still not sure what is worse: NIST accepting all kinds of KDF's without specifying a default construction and primitive, or these kind of papers (scrypt) that directly specify the primitive to be used. $\endgroup$
    – Maarten Bodewes
    Commented Aug 4, 2014 at 8:10
  • $\begingroup$ "Thus, the actual KDF you use might be e.g. PDFKD2-HMAC-SHA256" --> typo? Perhaps should be "PBKDF2-HMAC-SHA256" $\endgroup$ Commented Sep 1, 2021 at 22:13
  • 1
    $\begingroup$ @phoenixdown: Thank you, fixed. $\endgroup$ Commented Sep 1, 2021 at 22:59
4
$\begingroup$

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.

$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.