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:
dkLen=LowEntropy.length+HighEntropy.length
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?