Hot answers tagged key-derivation
14
The XOR is indeed meant as a protection against hypothetical short cycles. For a given password P, the sequence of Ui should make a "rho" structure: at some point in the sequence, a cycle is entered. For a n-bit hash function and random password, on average, there will be a single "big" cycle of size about 2n/2 and for almost all possible salt values, that ...
10
What you suggest is valid. Here is a way to show it:
In a fully implemented signature system (things are similar for asymmetric encryption), there are three modules:
a key pair generator, which produces a pseudo-random key pair;
a signature generator, which uses the private key to produce a signature over some piece of data;
a signature verifier, which ...
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
@D.W. is probably closest to the real reason (this was fifteen years ago, so things get a bit hazy), there was some concern about short cycles, and it was effectively free - you're already iterating the hashing deliberately to slow things down so speed isn't an issue - so why not do it? You've also got to remember the historic context, when replacements for ...
6
As mikeazo notes, PBKDF2 supports the generation of arbitrary amounts of key data. It accomplishes this simply by appending a running counter to the salt and rerunning the key derivation process to generate new output blocks, so there's no obvious reason why you couldn't apply the same construction to bcrypt.
The scrypt KDF also supports arbitrary-length ...
6
Short answer: just truncate, it's fine.
Long answer: you want a Key Derivation Function. A KDF turns an arbitrary-sized input (the shared secret obtained from SRP) into a configurable sequence of bytes, which you can split into as many sub-sequences as you need for symmetric cryptography. For instance, SSL/TLS defines a KDF (it calls it "PRF"; see section ...
6
To be honest, there's no good reason why the XOR is needed. My suspicion is that, most likely, the designers included it because they thought, "hey, why not? it can't hurt". But if the designers had left out the XOR, everything would have been just fine.
In particular, if PRF() is a secure pseudorandom function, and if we stick with typical parameters, ...
6
In my practice (Smart Cards, often using DES and increasingly AES)
Key Expansion is often used to designate production of subkeys in a block cipher. This process is often a mere bit extraction, as part of the algorithm's Key Schedule.
Key Diversification is, almost exclusively, the process of producing a device key from its serial number (or other ...
5
If the keys have constant, known length, I'd concatenate them, and then apply SHA256. If they have variable length, applying some separation mechanism might be useful.
Truncating hash functions works well. If the original hash function is good, a truncated hash function has the same properties, albeit at a correspondingly lower security level. Truncating ...
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'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
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 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
Leaving aside the question of whether or not this is a useful feature, my theory is the designer of PBKDF2 were familiar with the design changes made from MD5 to SHA-1 and felt that it might be beneficial to introduce a parallel data channel like the SHA-1 key expansion array (also constructed with XOR). With negligible overhead, the XOR doubles the ...
4
I agree with you. The XOR seems utterly pointless. A short cycle in the hash chain seems no more likely nor more unlikely than a short cycle in the hash/XOR chain. If one can degenerate into a sequence where additional iterations don't change the value, so can the other. If one can't, neither can the other.
4
PBKDF1 as specified in PKCS#5 and RFC 2898 provides Key Derivation and Key Strengthening. The parameters of the function are a hash function (such as SHA-1), a password, a salt (sometimes called nonce, depending on context), an iteration count and the length of the derived key to be returned. The standard PBKDF1 will just calculate the hash of password ...
4
Let's start with a general secure KDF construction, as follows. Let $F(k,x) \rightarrow \{0,1\}^n$ be a secure PRF. Then choose $L$ such that $L \times n$ provides as many output bits as you need for all of your generated keys. Let $S$ be your original secret key/entropy. Generate the following string:
$KDF(S,N,L) := F(S, C || 0) || F(S, N || 1) || ... || ...
4
You are using a Vernam-encryption (simple XOR), as for the one-time pad.
The general principle for Vernam is that it is perfectly secure as long as you never reuse the same key for more than one message, and gets utterly broken as soon as it is reused even once (this is the "two-time pad"). The key here is the hashed password, the message the key.
If one ...
4
You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence:
To generate the key material, compute [...]
until enough output has been generated. Then the key_block is
...
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
I can see a number of problems with your suggestion to let the session key $sk_{n,c}$ for node $n$ and client $c$ be $sk_{n,c} = h^{n+1}(masterkey_c)$, where $masterkey_c$ is what you refer to as "token":
You should use different keys for encryption and integrity, and different keys for the client -> node direction and the node -> client direction, making ...
3
To the best of our knowledge, SHA256 does not leak any additional information from related hashes.
On the other hand, the state of "our knowledge" might not be that comprehensive; this security property of SHA256 cannot be derived from the base security assumptions of a hash function (preimage resistance, second preimage resistance and collision ...
3
For your example protocol with RSA-exchange in both directions, combining both keys to one protects against some weaknesses:
By combining the random numbers from both sides, the result is really random,
even if one of them has a weak or compromised randomness source.
If one of the private keys is compromised, in your protocol the attacker can
read all the ...
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
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
