22
SHA-512 is a cryptographically secure hash, PBKDF2 is what we call a Password Based Key Derivation Function. If the resulting secret isn't used as key but as hash value it's also called a password hash. Password hashes differ from secure hashes in the sense that they contain a salt and a work factor / iteration count.
Both cryptographic hashes and password ...
19
No, you do not need to do escaping or sanitization on data that you pass in as the user input to these functions. They accept arbitrary byte sequences, so any arbitrary byte sequence you pass is acceptable, and there should be no security risks as a consequence of it. In general, cryptographic algorithms operate on arbitrary byte sequences (possibly of ...
18
This is called Client-Independent Update, according to the
Catena paper.
It is desirable to be able to compute a new password hash (with some higher security parameter) from the old one (with the old and weaker security parameter), without having to involve user interaction, i.e.,
without having to know the password. We call this feature a client-...
15
Password hashes need first pre-image resistance and should not cause many collisions among typical passwords (preserve the entropy). This collision "attack" violates neither requirement and causes no practical security issues.
While this issue can find trivial collisions, they're not between commonly chosen passwords. A SHA-1 hash (and thus the shorter of ...
14
Yes, it is. PBKDF2 derives a DK, a "derived key", which is indistinguishable from random. This is mainly because function within PBKDF2 is HMAC, and HMAC is a PRF. Let's see the definition from Wikipedia:
In cryptography, a pseudorandom function family, abbreviated PRF, is a collection of efficiently-computable functions which emulate a random oracle in ...
13
To paraphrase my answer to an earlier question, PBKDF2 is a generic high-level algorithm that internally calls a pseudorandom function (PRF) to process its input. The PBKDF2 spec does not mandate any particular PRF, so implementors are free to choose any PRF they want (as long as it meets the definition of a secure PRF, and can accept the input PBKDF2 gives ...
13
Assume you have an IND-CCA secure cryptosystem $E$ that runs a password through a slow KDF and implicitly handles salts and random IVs, a human-chosen password $p$, and messages $m_1$ through $m_n$ to encrypt. Is $E_p(m_1+m_2+\cdots+m_n)$ or $E_p(m_1)+E_p(m_2)+\cdots+E_p(m_n)$ better for this? Each invocation of $E$ is slow due to it running a KDF on $p$, ...
10
So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security?
PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step.
Bcrypt, however, is different.
In your case an attacker only needs a small amount of memory compared to ...
10
TL;DR: You want to use Argon2d here.
Even though Argon2 was standardized only somewhat recently, it is the result of the Password-Hashing Competition (2013-2015) and was a late re-design of Argon which also picked up ideas from a few other finalists. Since then there have been attacks on it, which caused the scheme to be tweaked to counter them better, this ...
9
That particular usage of SHA-1 uses HMAC, and then iterates that as part of PBKDF2 (which is actually defined for any PRF, not just HMAC-SHA1).
As of this date (2017-05-18) HMAC-SHA1 is unbroken in terms of collisions and other attacks, so PBKDF2-HMAC-SHA1 is still considered safe. The HMAC construction, along with the many iterations in PBKDF2, protects ...
9
You're right. Unless the software is doing something very peculiar, which should be very apparent when reading the code and documentation, and I can't imagine what it could be, the salt generation and the application of PBKDF2 are unnecessary.
If you have 32 bytes from a cryptographically secure random generator, you can use these 32 bytes as an AES-256 key....
answered May 12 '20 at 9:23
Gilles 'SO- stop being evil'
15.9k3 gold badges41 silver badges81 bronze badges
8
PBKDF2 (as defined by RFC 2898) is a function of the form
$$DK = \text{PBKDF2}(\text{PRF}, Password, Salt, c, dkLen)$$
In most practical use cases, the $\text{PRF}$ is $\text{HMAC}$ instantiated with a Merkle-Damgård hash function such as $\text{SHA-1}$. The time to compute $\text{PBKDF2}$ is roughly linear with the iteration parameter $c$, all other ...
8
TL;DR: Yes, you can use PBKDF2 as a stream cipher. However, you should not use it for that and for its intended purpose (i.e. password-based key derivation) at the same time. Instead, if you need to do both, call it twice.
PBKDF2 is a password-based key derivation function — or, rather, a scheme for constructing such a function out of a variable-key-...
8
I think you are overstating the complexity of PBKDF2, and also, not matching it feature-wise with your alternative. Let's dispatch the latter first: as gammatester's comment mentioned, PBKDF2 supports variable output size. If you built that into your proposal, it would become more complex.
Once we control for that, PBKDF2 is hardly more complex than your ...
7
So, here's my question: is there a point where the salt size doesn't matter anymore in terms of security and where it might even decrease it?
The purpose of a salt is to prevent the attacker from targeting multiple users' passwords with the same try or caching common passwords' hashes in a table. You need enough salts that each user has a unique salt. After ...
7
Firstly, How much time will it take to crack PBKDF2 while using a 9 character password? and how do I calculate the cost? I'm not specifying any specific system or platform. If a brute force attack is made using the best ever super computer around how much time will it take to crack it?
Unless the underlying PRF is broken, brute force and dictionary attacks ...
7
There's no practical limit to password or salt length you can use with PBKDF2.
Theoretical limit, however, is determined by the hash function used by PBKDF2: under the hood, it uses $HMAC(Password, Salt || Counter)$, which in turn will translates to a series of hash function calls:
$K_0 = H(Password)$ (assuming password is longer than hash block)
$HMAC =...
7
These hash functions are also used for the key derivation function. Both are roughly equally secure for a KDF in the sense of collision resistance etc., but SHA512 offers a bit more security as countermeasure for custom hardware attacks, since the memory requirements are a higher than for SHA256 and custom hardware to crack the passwords like FPGAs is more ...
7
All the parameters you've mentioned can be public. Furthermore, only the salt, IV and ciphertext cannot simply be guessed.
The IV is generally easy to retrieve once the key is known, so the making the IV secret doesn't make sense. In CBC mode and many other modes you may just not get the first plaintext block if the IV is completely absent, but the rest of ...
7
There's no point in using either an ASIC or a GPU to calculate a single password hash. That's true whether you use PBKDF2 or scrypt or Argon2 or whatever.
What massively parallel devices like GPUs or ASICs are good for is hashing millions or billions of passwords at the same time. That's useful if you're mining a cryptocurrency or trying to crack a hash ...
6
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 ...
6
Is there anything wrong with swapping SHA2 for Keccak for use in PBKDF2?
There are 2 main issues. Performance and implementation.
Performance
The performance issue is from an attacker-defender scenario, where the attacker is able to provide FPGA or ASIC resources. In this scenario, Keccak is several times faster than SHA-2. I will use a Blake comparison ...
6
No, you should not use a password directly as an HMAC key.
However, it is fine to use HMAC as part of a key derivation function, which generates keys from a password. However, do not mistake the output as naturally having higher entropy than whatever you put in. "password" has essentially 0-bits of entropy, and running it through a KDF will not magically ...
6
The only downside to SHA-2 over SHA-1 is that SHA-2 is a little slower.
In this case, that is of no practical consequence whatsoever because you're trying to make something slow to compute, and it is only a matter of raising the number of iterations to make it cost a certain number of bit operations in serial.
However, please consider using the modern ...
6
From an information-theoretic perspective, and with an ideal password hash function, with $k=68$ possibilities for each character of derived password, each such character leaks about $\log_2(k)\approx6.1$ bit, but only as long as that remains significantly lower than the entropy in the master password. That's a leak of about $73$ bit per derived password. ...
6
The question correctly finds that
In the case of PBKDF2, you will need to buy an ASIC to be ideal
and proceeds assuming the legitimate server does that; or at least, uses a GPU as substitute. Which, in practice, does not happen. That's where the question's reasoning drifts from reality.
When we compare PBKDF2 to Scrypt, and conclude the later is vastly ...
6
Background.
PBKDF2 has a stupid design where generating two blocks of output costs the legitimate user twice as much as generating one block of output, without necessarily putting additional cost on the adversary's task of confirming a password guess. This is because each block of PBKDF2 output is generated by iterating the PRF on distinct initial inputs, ...
6
PBKDF2 is deliberately slow (and gets slower and safer with more iterations, so you want to make it as slow as you practically can). Because of this, you should generally avoid running it more times than you absolutely need to.
Using the same key and a different IV for each encrypted document is indeed OK — that's what the IV exists for. Most encryption ...
6
You need a key stretching function, not a mere key derivation function. A key stretching function is technically a kind of key derivation function, but most key derivation functions are not key stretching functions. A key stretching function is intrinsically slow to reduce the possibility of brute force guessing, and includes a salt input to make ...
answered Jul 22 '20 at 1:26
Gilles 'SO- stop being evil'
15.9k3 gold badges41 silver badges81 bronze badges
5
I agree with the comments that SHA-256 should be fine here.
However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply:
$$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$
where 'info' is an optional, ...
Only top voted, non community-wiki answers of a minimum length are eligible