I'm looking at some code that encrypts data in a database using AES. Before doing so, the encryption key is passed through a PBKDF2 function. Reading up on this, it appears this is for when the key space can be guessed, i.e. like someone's password that might use words out of an English dictionary. The encryption key however is purely random, something like:
M39UrEEveje3J#PB=jPG9+&eUSTJG*SAK&s_xHLRu$?Hrbg&7Vn5X^P298$W2z2#r6_!yfGQMQ@ArXjgefq-?9^b?y786ZL5cYcqE6#!c4@rE$scZxR$$e6cYPX$U-m7
In a predictable key space, you want there to be an increased workload for brute-forcing the encryption. Thus, hashing the password through so many rounds of PBKDF2. If the key space is completely uniform and non-predictable though, isn't this just a waste of CPU cycles? Is it good practice to do anyways?
/dev/random
or equiv) to populate a byte array, and that string is some kind of pretty-print of the byte array. On the other hand, if you're actually generating ASCII strings and using them as keys, then your key space is probably a lot smaller than you realize and you should see AndrolGenhald's answer.