Were you using it to hash data for integrity? Or even worse, were you abusing it as a MAC [1]? That's the only way I can see it being so slow. PBKDF2 is a pa

Were you using it to hash data for integrity? Or even worse, were you abusing it as a MAC [1]? That's the only way I can see it being so slow. PBKDF2 is a password-based key derivation function (it says so, right in the name), not a data integrity verification function. You should only ever be feeding a password and high-entropy salt into it. It's something of a disservice to call all these things "hash functions". It makes people think they're interchangeable, but that's very far from true. [1] The reason I say using it as a MAC is even worse than using it for data integrity is that was never intended to work as a MAC. A KDF doesn't care (in theory) if the salt input can be derived by looking at its output. For the intended use case of a KDF, the salt is stored with the output anyway. So a cryptanalysis of a KDF wouldn't see the revelation of information about the key by the output as a theoretical flaw. But that would be a huge flaw in a MAC, where the output is often conveyed by an untrusted party between two parties who keep the key secret. From a practical standpoint, a KDF that did leak details of its key in its output is inefficient (redundant use of storage space), but it isn't sufficient by itself to break the security properties.