Hot answers tagged pbkdf-2
10
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
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 ...
8
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 ...
7
Cryptographically speaking, AesManaged uses AES in CBC mode. To ensure this operates securely, you need to choose the IV randomly, i.e. it should not be possible to predict the IV between iterations. This question has a discussion of non-random IVs: Using a Non-Random IV with modes other than CBC and this SO question: Why is using a Non-Random IV with CBC ...
7
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 ...
6
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 ...
5
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 | ...
5
You are correct that using a different salt for each file will slow down encryption and decryption, in proportion to the number of files. But it is not useful to do so. An adversary is not helped if she knows that the salt is common to several files hashed with the same password (under the assumption that she can recognize a correct password with fair ...
5
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 ...
4
Don't. Just don't.
You are indeed perceptive enough to note that if the output of PBKDF2 is truly pseudo-random, then XORing it onto data is as secure as the password is. But don't. Really. It's not good hygiene. A KDF is a Key Derivation Function, not a cipher. It's not designed to be used as a cipher, so don't use it as one. Use it to derive keys that you ...
4
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 ...
4
It's fine, as others have noted.
However, by invoking PBKDF2 twice (first to check the password, then to derive the actual key), you're essentially doubling a legitimate user's workload, whereas an attacker still only needs to run it once for each guessed password. Thus, you're cutting the legitimate user's advantage in half, or, equivalently, wasting one ...
4
No it cannot be used to create an OTP as the technical definition of OTP requires that the pad be truely random and the output of PBKDF2 is not true random, only pseudo-random.
Of course you can generate a large pad from a password and xor it with your random plaintext. What you lose though are strong security guarantees. AES has been hammered at by really ...
4
Using the password itself (or anything similar predictable) instead of an independent random value as the salt denies the whole benefit of salt:
Same passwords (passphrases) give now the same key, instead a different one. So, if two users happen to choose the same favorite image as their password, they get the same key, and thus an attacker can use this ...
4
Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose.
In fact, Wikipedia says:
$v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended.
Thus, you could use ...
4
That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue.
I disagree with Polynomial who ...
4
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
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 ...
3
I'd assume the sample (since it isn't listed) is storing a salt per encryption, because that sample assumes that only the password is variable and has no concept of users.
Using the salt per user is effective because the difficulty of using a rainbow table goes up per user (if the user table is compromised), and per your question additionally salting per ...
3
No, it should not be necessary to derive a unique key for each message, although it certainly shouldn't do any harm, either. CBC mode is provably secure (in the IND-CPA sense, or even IND-CCA2 if combined with a MAC) even if the same key is used for multiple messages, as long as the underlying block cipher is secure (a PRP) and the IVs are distinct and ...
3
The OP wants a Key Derivation Function suitable for producing a key for the block cipher TEA, from Password and Salt. He is considering the use of PBKDF2, a common method designed for that purpose, which has a parameter controlling how slow the computation is, and thus the difficulty of password cracking.
PBKDF2 is a giant progress compared to practices ...
3
Yes you can use PBKDF2 for both (from section 3 of this memo)
Another application is password checking, where the output of the key
derivation function is stored (along with the salt and iteration
count) for the purposes of subsequent verification of a password.
Also (as mentioned in the comments of this post), the memo also says (emphasis ...
3
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 ...
3
Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret.
The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow ...
3
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 ...
2
I would use an encryption method designed for the purpose, such as AES Key Wrap.
That said, PBKDF2 uses a PRF internally, so if you specify an iteration count of 1, your suggestion would effectively amount to using a PRF in CTR mode. Since you put the question that way, then, yes, it would be good enough, in the sense that the weakest link would probably be ...
2
Yes, this is secure.
Given your statement that the master_key is a cryptographic-quality 128-bit random value (not a passphrase), you do not need to use PBKDF2. You can use any key derivation function, and you can use any secure one. For instance, any any pseudorandom function (PRF) will be adequate, such as AES-CMAC. Also, HKDF would be fine, too.
Also ...
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.
1
The output length of the F step of PBKDF, i.e. the T_i each are of the size of your hash function's (or actually: your PRF's) output.
So yes, when the desired output size is as large (or smaller) as the hash function output, we have l = 1 and thus only one call to F(P, S, c, 1).
I suppose this is also the most common way to use PBKDF-2, the extension to ...
1
There really isn't any measurable security in that. It's also inconsistent. If you had thirty text 1KB files, you'd be generating thirty new schedules, but if it were one 20MB video, you'd be using one schedule for all of the data.
Really it depends on your mode of encryption. For example, if you're using CFB the iv would change depending on the previous ...
Only top voted, non community-wiki answers of a minimum length are eligible
