# Tag Info

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 ...

6

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 ...

6

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

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 ...

5

The same key is indeed used in EAX to key both the CTR mode and the underlying OMAC (which is actually used in 3 distinct phases: randomising the CTR nonce, authenticating the Additional Authenticated Data, and authenticating the Ciphertext). This is explicitly acknowledged in the security proof. Where EAX differs from a naive reuse of the key is that it ...

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

There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other ...

4

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 ...

4

As noted in archie's answer to your earlier question, the EAX paper first defines a generic encrypt-then-MAC composition method called EAX2, with separate keys for the encryption and MAC components, and proves its security (Appendix C). It then defines EAX as EAX2 instantiated with CTR mode and OMAC, and with the same key used for both components, and then ...

4

Is there a better way to do this? Yes there is, using tools specifically designed for this problem - namely key derivation functions (KDF). Good ones include PBKDF2 and bcrypt. A more modern, better alternative is scrypt, but it's relatively new and could use some more analysis before deemed safe. All above mentioned algorithms take a password and a ...

4

Of course you can - but as to whether or not it's a practical or advisable idea, I don't think so. It's not really prudent to implement crypto systems/protocols and assume that they'll be fine in 10 years. Cryptography is a dynamic field that changes rapidly; algorithms get broken, hardware improves, governments try to undermine the field, and attacks only ...

3

The shared secret generated by the Diffie–Hellman key exchange is a random element of the subgroup of the multiplicative group modulo $p$ generated by $g$. In particular, for $g$ and $p$ chosen as specified in RFC 2631 section 2.2, i.e. so that $p = jq+1$, where $q$ and $p$ are both prime, $j$ is a small number (often 2, making $p$ as safe prime) and $g$ ...

3

If I understand correctly is to hash your password $pw$ into a point using either $P=Pad(pw)\cdot P_0$ or $P=MD5(pw)\cdot P_0$ and then use $P$ for cryptographic purpose. The exact security of this proposal depends on what you want to do with $P$ exactly. But in some case, this is not secure. Typically, this mechanism is not a good way to hash a password ...

3

Answering your three questions in order: "If I have a lot (more than $2^{32}$) of files to be encrypted, each file is encrypted using newly generated DPK. Will it somehow cause the MK to be easily found? or easier to find?" It's not going to make it harder. But no, as long as the KDF you're using lives up to its security claims, in practice it should ...

3

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 ...

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 ...

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

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

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

One of the advantages of schemes like scrypt and bcrypt is that they are designed to be "hard" to brute-force. That is, the actual guts of the algorithm are designed to continuously use something that is difficult for a specialized implementation to speed up. For example, scrypt is based on sequential memory-hard operations, which makes sequential memory ...

3

To begin with, I see four potential problems with your key file. The work factor (8) is probably too low. If we presume you pick your pass phrase by selecting $c$ words at random from a list of $2^{13}$ distinct words (e.g. correct horse battery staple) you get a pass phrase with $13c$ bits of entropy. (AFAIK the dictionary used by Diceware only barely ...

3

Of course it's possible; all you need is take your cryptographically secure input, feed it as the key to a CSRNG, and then use the CSRNG output as the source of randomness to an RSA key generation algorithm. For a concrete example, there are several such key generation methods in FIPS 186-3, with the cryptographically secure input being the 'seed' (and you ...

3

You want a pair of functions $(f_1,f_2)$ from a set $S$ of possible passphrases to a key set $K$, that is $f_1,f_2: S \rightarrow K$. The functions are public, in the sense that they can be computed by anyone. Your security goal is that the cost of finding $f_2(pw)$, knowing $f_1(pw)$, should be roughly as expensive as finding $f_2(pw)$ by searching for ...

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

In addition to the severe problem that minar has shown, using point multiplication has an additional problem; some of the output bits can be computed as a function of other output bits. This is a property that we generally do not expect from a key derivation function. Here's how this works: an ECDSA public key consists of an "X" coordinate and a "Y" ...

2

Taken directly from the RFC: The second stage "expands" the pseudorandom key to the desired length; the number and lengths of the output keys depend on the specific cryptographic algorithms for which the keys are needed. The use of the plural here suggests (at least to me) that yes, it's ok to expand the same PRK several times with different ...

2

I'd still go with HKDF. Since you already have a good uniform master key, you can skip the extraction step. So HKDF simply becomes HMAC-SHA-2(masterKey, info+\x01) I'd start info with a string identifying your use, and add the user specific information after that. Your system should be secure as well as long as you only produce a single block of output. ...

Only top voted, non community-wiki answers of a minimum length are eligible