0
$\begingroup$

am sorry, an a beginner, so please forgive me if i make mistakes, so here is what I understood:

PBKDF2: uses HMAC, so, the message is the password, and the key that crypts the message is the salt? or is it the inverse? and this is done the number of the rounds $n$ times.

So I guess the second one, because the user will write the password, and then the program will consider this as a key to decrypt the salt?

BCrypt: used to avoid custom hardware cracking, altering the table where the hashes are stored to make the result unpredictable so to force the program to wait and to block? and using only 4KiB in CPU cache to block the program (GPU will become slow since they dont have cache? )? BCrypt encrypts the password using a key derived from the same password using Blowfish $2^n$ times?

SCrypt: kind of BCrypt but...uses lot of memory to block the process on a huge amount of memory, to block the calculations and force the program to wait?

So, BCrypt uses a small amount of CPU Cache, while SCrypt uses a large amount of RAM?

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ why dowvoting :( $\endgroup$
    – Abdelouahab Pp
    Jun 9, 2013 at 18:45
  • 1
    $\begingroup$ Scrypt uses huge amounts of RAM to prevent custom-hardware attacks and to make blind, brute-force type attacks more expensive. Bcrypt has a long key creation process but once it's made a key, it doesn't change anything where the key is stored. GPUs do have caches but even if they didn't, they'd still be faster than your typical high-end CPU (because they use hundreds, even thousands of processors). $\endgroup$
    – rath
    Jun 9, 2013 at 22:40
  • 1
    $\begingroup$ What do you mean by 'block' the program? $\endgroup$
    – rath
    Jun 9, 2013 at 22:41
  • 1
    $\begingroup$ In PBKDF2, the salt is the message sent to the HMAC, and the password is the key to the HMAC. I referenced this implementation: openbsd.org/cgi-bin/cvsweb/src/lib/libutil/… $\endgroup$
    – John Deters
    Jun 10, 2013 at 14:33
  • 1
    $\begingroup$ @AbdelouahabPp, yes, a key longer than the blocksize of the hash will require extra work. Primarily, though, the number of rounds chosen has a much bigger effect on time taken. Remember that consuming time and/or resources is the whole idea behind specialized password hashing, and that the longer each PBKDF2 iteration takes, the less practical an extensive brute force attack becomes. $\endgroup$
    – John Deters
    Jun 10, 2013 at 21:43

1 Answer 1

Reset to default
2
$\begingroup$

Each of these algorithms has a similar process:

$K_{i+1} = R(K_i)$

Where $K_0$ is set to some concatenation of the plaintext password and optionally a salt value, and $R$ is the algorithm specific "round function". The number of iterations is also adjustable by the application.

As you said, the input of the next round comes from the output of the previous round, which forces the work to be done in serial. A program that uses this need not block, it could be done in a separate thread.

The algorithms differ in their choice for $R$. It seems that BCrypt uses a function based on Blowfish, while SCrypt $R$ relies on a large lookup table. They all have the same purpose, to make checking a large number of hashes as resource hungry as possible, while trying to minimize user inconvenience caused by a small delay in checking a single password.

Improve this answer
$\endgroup$
1
  • $\begingroup$ SCrypt uses a lot of memory, but BCrypt uses only 4KIB ? $\endgroup$
    – Abdelouahab Pp
    Jun 10, 2013 at 19:17

Your Answer

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

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