How many different keys can be derived with HKDF before two outputs are identical? How many different keys can be derived with HKDF before two outputs are identical?
This question is about collision resistance, not about generating different keys with different parameters (eg. different salts/info parameters).
For HKDF with SHA-256 would it be $2^{128}$ since the collision resistance of HMAC-SHA-256 is 128 bit?
I've seen this a few times, so I want to point out something that is a general misconception. People often think that for key derivation, it's really important that I don't get repetition, since that is a break. However, this is actually very not true, and the opposite is true. I will explain.
The &quot;ideal situation&quot; is to just choose keys, truly at random. In this case, if I am working with 128-bit keys, the birthday paradox still holds. As such, after generating $2^{64}$ truly random keys, they will repeat. This is not a problem at all. On the contrary, it guarantees that even if you saw all of the previously generated keys, you have no information on the next one. Furthermore, all (symmetric) encryption uses an IV, so you'd need the random IV and the key to collide in order to be able to detect that two different people/cases are using the same key.
One would think that it would be better to choose keys purposefully so that they don't repeat. But this would mean that keys get less and less random, and have lower entropy as time goes on. In particular, given past keys, the new key is known to not equal any of those. So, we actually do not want to do that.
Just to stress this, using AES for key derivation directly (e.g., in CTR mode), the quality of the key derivation goes down when you get close to the birthday bound because the keys can't repeat. Thus, since the keys can't repeat, that means that the key does not look like a random one. I know that this is the opposite of most people's intuition, which is why I felt it important to point out.