41
The best you can hope for is the following:
You derive the password into a "big enough" (e.g. 128 bits) secret key $K$ with a Key Derivation Function like PBKDF2. There are some details to be aware of (see below).
You use the secret key $K$ as seed for a Pseudorandom Number Generator. The PRNG is deterministic (same seed implies same output sequence) and ...
25
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 ...
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-...
16
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 ...
14
First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt
It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per https://www.owasp.org/index.php/...
13
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
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$, ...
12
I'd use HKDF's "expand" step to generate multiple keys from one masterkey.
Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2.
//Extract
MasterKey = PBKDF2(salt, password, iterations)
//Expand
AES-Key = HMAC(MasterKey, "AES-Key" | 0x01)
MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01)
(where | ...
11
I suppose that what you are trying to do is password-based encryption of some data; you use PBKDF2 to derive the password into an encryption key, and then use the key with AES to encrypt the data. The AES encryption needs an IV, and the PBKDF2 function needs a salt. Both IV and salt should be generated anew for each encryption (even if reusing the same ...
11
A common approach is to encrypt the private key with a symmetric key derived from a pass phrase. This will be as secure as the chosen pass phrase. I'd suggest sticking with this approach; its conventionality makes it "simpler" than a solution that hasn't been studied well.
11
For the purpose of key diversification (that is, assigning a unique key per device), a true master_key is customary; that is, one with plenty of entropy (like, 128 bits or more random bits). Edit: that's now stated in the question.
With that caveat, yes, PBKDF2(password=master_key, salt=serial_number, rounds=1000, dkLen=16)is appropriate to generate one 128-...
11
If you want key diversification with a key as input, you are better off using a key based key derivation function (KBKDF) over a password based key derivation function (PBKDF). Difference is that KBKDF requires a key with high entropy. This also means that it does not require a salt nor an iteration count. It does however require context specific data for ...
10
You were doing fine up to the point where you wrote "JavaScript".
Of course, JavaScript as a language is not fundamentally unusable for crypto (although, as a high-level scripting language, any crypto primitives implemented in JavaScript are likely to be rather slow and hard to secure against side channel attacks). However, when you write "JavaScript", I ...
10
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 ...
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 ...
9
Use gpg --s2k-mode 3 --s2k-count N, where N is the number of iterations you want to use. The manual page says the default is 65536, and you can use any number between 1024 and 65011712.
If you like to tweak the defaults, I suggest making this number as large as you can bear it, without introducing noticeable slowdown (e.g., ideal would be to make the ...
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 ...
8
Identical passwords will still get unique PBKDF2 hashes given a unique salt, regardless of which mechanism you use.
I don't think explicitly adding the salt improves the security of this scheme. The designer PBKDF2 have already considered and solved this problem. There is no need for you to try to duplicate their efforts.
I think it's safer to use the ...
8
PBKDF2 uses the password as the PRF key.
From the RFC:
The first argument to the pseudorandom function PRF serves as HMAC's
"key," and the second serves as HMAC's "text." In the case of PBKDF2,
the "key" is thus the password and the "text" is the salt.
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
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 ...
8
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 ...
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
Summary: I don't know of any good reason why it has to be this way. In practice, I don't think it is necessary to inject the password into every iteration. As far as I know, I think the construction would still be secure (in practice) if you used the salt and password only in the input to the first iteration, and then just repeatedly hashed the result many ...
7
Hash algorithm strength is important, but it is not so important in key derivation functions. It is unlikely that even if SHA-1 is broken that it would influence the security of PBKDF2. You are better off using SHA-1, and increase the iteration count up to a level that is tweaked for your specific configuration.
If you must, you could use Bouncy Castle to ...
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
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-...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
