# Tag Info

5

I agree with the comments that SHA-256 should be fine here. However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply: $$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$ where 'info' is an ...

4

Given a EC public key, can a different, but plausible and functional private key be derived to match the public key? No, a public key will correspond to only one private key (with one minor exception, which I will explain below). With Elliptic Curve systems, the private key is an integer $d$ between 1 and $q$ (the order the generator point $G$), and ...

2

If you are concerned about database size, only the master key needs to be stored when you use HKDF. Ditto when sending it to another computer. Otherwise, two independent random keys are clearly secure and simpler to implement, so you should do that.

2

Is it subject to some class of attacks or is it just a really bad crypto nightmare which is only subject to brute-force attacks? You are calculating PBKDF2 twice, which takes twice as long. An attacker doing a brute force or dictionary attack only needs to calculate one of them to verify his guesses. That means you are making attacks twice as easy as ...

1

If you are certain that SecureRandom is a trusted, verified CSPRNG you can use that without HKDF without problems.

1

Although the answer is already accepted, I'll add an answer with a different look on things. It's safe, but that's not what HKDF-expand should be used for. The idea of HKDF-expand is to call it twice, once for each key, using the info element to distinguish between the two (e.g. info could be an ASCII encoding of the key name). Note that HKDF should have a ...

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