When I learn PBKDF2, I found out most of the articles say that the PBKDF2 use HMAC as PRF. Why is HMAC? Can I use other pseudorandom functions? Is HMAC safer than any other functions for PBKDF2?
1 Answer
TL;DR: Bit values of passwords are "weirdly" distributed and hash functions (and thus HMAC) are generally believed to deal better with them.
Why is HMAC?
Presumably originally the idea was to improve on previous designs which were all very hash-focused. People wanted to use hash functions in some way to process passwords. But the designers of PBKDF2 probably considered it wise to use a PRF (thereby reducing assumptions on the underlying function) and HMAC is the standard way of turning a hash into a PRF. Also they probably liked the idea of not having to jump through hoops to define ways to process arbitrary-length passwords.
Can I use other pseudorandom functions?
So, if your password was a uniformly random bit sequence, then yes absolutely you could use other PRFs and get a PRF out of PBKDF2. However, passwords generally don't stay to that model. In that case one usually turns to hash functions to map a high-entropy non-uniform value to a high-entropy uniform value.
Of course the above argument raises the question "what about KMAC and other hash-based PRFs"? They should work similarly well as they tend to inherit the security advantages of their underlying hash functions. Note however that some such constructions (not KMAC) have weaknesses with regards to variable-length keys. For those fix the length of your salt.
As for actually using KMAC (and this Keccak / SHA-3), this is a difficult situation. In principle it works. However you usually want to use functions for password derivation where the optimal ASIC to brute-force it would essentially be the hasher's normal CPU (or only marginally better). However until we get specialized Keccak extensions dedicated Keccak circuitry will likely be much faster than software implementations making PBKDF2-KMAC a much inferior choice to e.g. Argon2.