Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am developing a mostly-offline authorization system that authorizes a user using an deterministically generated AuthKey derived from a MasterKey derived from a high-entropy chunk of data (128 bits) and a low entropy data (for example, an email address).
The total length of the concatenated data will never be more than dkLen (256, either by hashing the low entropy data using md5 or using padding), and AuthKey will be used in order to generate a ECC asymmetric pair.

MasterKey = KDF ( HighEntropy, LowEntropy )

AuthKey = KDF ( MasterKey, keynumber )

For this purpose, and in order to avoid bruteforce I am considering using hkdf or scrypt.

My primary concerns are:

  • Are there considerable chances of key collision?

I know that just with the 128 bits of entropy there are 3.4028237e+38 combinations, even more with the low entropy data.
Still, provided that no one used the same LowEntropy value, and considering:


Is It possible for two different AuthKeys to collide?

¿After applying a KDF to the 256 bits of data, and getting 256 bits of data, will the chance of collision be reduced or increased?

  • Is there any reason, given the previously exposed model, to choose HKDF over scrypt?

As far as I have read scrypt requires more resources and therefore is more costly to bruteforce, a recent question suggests that

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.

The thing is I want HighEntropy and LowEntropy to be a headache to bruteforce, if possible, even in a long-term post-quantum cryptography futuristic enviroment.

  • Also, is there any reason for the either the highentropy or the lowentropy data to be used specifically as key or hash?
share|improve this question
Just a note: don't use MD5. While it might not be broken for the purpose you are using it for, its collision resistance is broken, and attacks only get better. – Paŭlo Ebermann Mar 14 '13 at 21:09
@PaŭloEbermann besides that, if you ever are asked to deliver a product to an organization that takes security seriously, using MD5 or even SHA-1 is the equivalent to taking a red flag to the middle of a battle field (I've got the scars to prove it :) ). – Maarten Bodewes Mar 17 '13 at 16:02
up vote 3 down vote accepted

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 different, the derived AuthKeys will be different, too.

You don't need to use scrypt if you are using a 128-bit crypto key (assuming the crypto key is kept secret and not revealed to others).

I don't understand what you are asking when you talk about using multiple times the same ECC key. I think you should post about that separately, as it sounds like a separate question. (On this site, we want you to post one question per question; if you have multiple different questions, please post them separately. Don't forget to read the FAQ.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.