I have a single password which is random bytes that encrypts a database. Right now I am using an encryption scheme of https://gist.github.com/jbtule/4336842. To summarize, we take our one password, generate a salt for an auth key and a crypt key, run PBKDF2 with 10,000 iterations to generate the keys, then use AES to encrypt and HMAC to authenticate. The salts are then stored next to the ciphertext.
My issue is that the key generation is becoming prohibitively slow. Encryption and decryption are happening along side other heavy CPU procedures and many queries, and therefore many decryptions, occur for any given procedure. Sometimes the key generation step can take ~5 seconds per element I want decrypted. But as I am reading about it, it seems key derivation functions aren't necessary for my use case as the original password is totally random.
I am thinking of just taking the single password and concatenating it with crypt and auth salts before the AES and HMAC encryption/decryption. I might also simply turn the PBKDF2 iterations down to something low like ~10, which might look sloppy but would involve changing less code and less testing. Is there a security vulnerability that I am missing here? Would either of these solutions open me up to an attack, brute-force or otherwise? From what I am reading about key generation it seems like I don't need it, but homebrew solutions are always bad so I am very cautious in removing any security we have. Thanks for your help.