Hot answers tagged key-derivation
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 ...
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 ...
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
KDF must produce results that have certain randomness properties, and be very difficult to reverse. Password hashes only need to satisfy the property "difficult to reverse", without randomness requirements. This is why all KDFs work as password hashes but not the other way around.
5
I am familiar with the RC4 related key attacks; I can say that if you publish the nonce, and use any of the first 256 bytes of the RC4 keystream, that you are vulnerable to those attacks.
These attacks exploit a correlation between specific bytes of the RC4 key, and the initial output values; with your approach, the attackers can guess what (say) byte 2 of ...
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
Yes, this is a fine approach. This sort of technique is known as "key separation".
Since your master key is a cryptographically secure key, you do not need to use a large iteration count. Also, you could use any PRF, in place of PBKDF2. (The iteration count is normally used if you are applying PBKDF2 to a passphrase, instead of a cryptographically secure ...
3
If you have a high entropy input, then scrypt isn't a good choice. It's purpose is to compensate for the low entropy of a password. Don't ask the user for memory/cpu factors, you don't need them if the input is high entropy. You don't need a salt either.
Simply use an input of at least 16 bytes from a secure random number generator.
I recommend using one ...
3
The point of a KDF is to take a low-entropy input and significantly increase the amount of computational power (and thus time or cost) it requires to brute-force, hopefully to a level on-par with a truly random value.
If you're already using a 256-bit value generated from a CSPRNG, there is no need to use a KDF.
In fact, using a KDF can only reduce the ...
3
Take the following points into consideration:
A 32 character password composed of 95 ASCII characters only has $\log95^{32}\approx 210$ bits.
As long as there are no quantum computers (which would reduce the key strength to 105 bits), that's not a practical problem.
Not taking the previous point into account, if your password really gets generated ...
3
There are two forms of entropy here at work. First there is "uncertainty" entropy from the user password which is typically very low (on the order of 20 to 40 bits for most passwords out there). And then, there's "computational" entropy, which is artificially obtained by forcing an attacker to do work to calculate keys.
Essentially, if you run your KDF for ...
3
There are two answers: the "engineering" answer, and the "principled" answer.
The engineering answer is that, in practice, if you generate two keys using two different info strings, I suspect you'd probably get away with it without problems. If we model the hash as a random oracle (admittedly a very strong "assumption"), then I suspect it might be possible ...
3
A key derivation function is intuitively "purifying" the entropy in the group element Z into uniformly random (looking) bits that can used as a key for other purposes. It is not designed to produce "multiple keys" from the same Z, and one should definitely not call the KDF on the same Z twice (even with different salts) and expect to get two independent ...
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
Well, if you are using CBC mode in the recommended way (always using an unpredictable IV), then it turns out to be easy.
With CBC mode, the value that is presented to the encryptor is always a plaintext block exclusive-or'ed with an IV or a previous ciphertext block. If plaintext blocks are uncorrelated with both the IV and the previous ciphertext block ...
3
I see no reason why that would not be secure. If you want to play it safe, though, you could always go with a standardized key derivation function, such as HKDF (RFC 5869) or one of the other KDFs listed in this draft standard. (The draft itself seems to be expired, but it's the most convenient list of standardized key derivation functions I could find.)
3
No, the info is not a salt. The input key material for a KBKDF (key based key derivation function) should already be pseudo-random, and should therefore contain enough entropy to not need a salt.
If the user already has a unique 16+ pseudo-random bytes key then there is little reason to use the email address as part of the info. The email address could be ...
3
I don't think this is a great idea. I don't know of anyone who has analyzed it carefully, but it is basically relying upon RC4 to be secure against a particular kind of related-key attack (one that probably hasn't been studied much).
We know that in general RC4's key schedule algorithm is not very resistant to related-key attacks. For instance, it is a ...
2
What you are doing sounds a lot like what the /dev/random and /dev/urandom or the PRNGD on many systems already do:
those systems take an arbitrary large sequence of numbers (from a true hardware random number generator if available, or else from environmental noise such as keystroke timing)
and feed it into a CSPRNG.
The CSPRNG internally maintains an ...
2
What you want is a key derivation function (KDF). Here's a fairly thorough list of some standardized ones.
Ps. The suggestion given by user1852723 to use HMAC, with your "seed" as the key and a counter (or other non-repeating sequence) as the input, more or less corresponds to the "Counter mode KDF" construction described in NIST SP 800-108, with HMAC as ...
2
What you are describing is called output feedback mode, a mode of operation for block ciphers to create a stream cipher. You are discarding the first 996 output blocks and are using the following four ones.
In general, your algorithm (as any algorithm) can't produce randomness, just stretch existing randomness in a way which might look more random.
If ...
2
The algorithm you describe seems to have a class of special states (similar to the Finney states of RC4) consisting of the states such that $i = j$ and $k_x \bmod L = 1$, where $x := k_i \bmod L$.
If we are at a state that belongs to this class at the beginning of the loop, the effect of the loop will be simply to swap $k_i$ and $k_{i+1}$ and to increment ...
2
Instead can't we generate object specific keys "on the fly" using HKDF using a master key and object id as inputs, so that we dont have overhead of storing and managing keys each time?
Sure you can. I've got an even easier method. Just use the same key for everything. No key derivation or key management needed. Or even better, don't encrypt anything. No ...
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
It's called key derivation because it is used to obtain a "strong" key based on a key you own and is not so strong. Suppose a user has a password 12345 and an online service needs authentication. In order to verify the correctness the server doesn't store 12345 but it stores bcrypt(12345+salt) which further makes is more difficult for an attacker to break ...
2
No, you don't have to worry about collisions.
As long as no pair of users have the same LowEntropy input, they will receive different MasterKeys. If the MasterKey is different, then the AuthKey will be different. Even if you use the same MasterKey to generate multiple AuthKeys, you don't need to worry about collisions: as long as the keynumber values are ...
1
Let $n$ be the number of "memory cells", and $t$ the number of iterations (i.e. the three steps you describe in your question). Then we see that at each iteration, each cell has an equal probability of being picked. Then, the probability that any one cell is not selected on this iteration is:
$$1 - \frac{1}{n}$$
And hence, the probability that one cell is ...
1
In theory, someone could do this, but in practice nobody really uses random, sketchy third party cryptography software. Most, if not all, of the commonly used cryptography functions are well understood and tested. Most of them also openly reveal precisely how they work so anyone can implement them. This means lots of people can analyse the algorithms for ...
1
Since a good block encryption algorithm, e.g. AES, running in counter mode, i.e. encrypting some more or less arbitrary chosen (unknown to the opponent) input values, is generally considered to be sufficiently secure, IMHO that could provide a rather simple and convenient way of deriving a large number of keys from a given master key. One could that way even ...
Only top voted, non community-wiki answers of a minimum length are eligible
