Reason(s) for using a KDF for encryption keys Assuming I already have a 256-key (32 char password) for AES encryption, comprised of random alpha-numeric characters and punctuation (95 possible ascii chars), generated by a decent PRNG, is there any reason to use a KDF to convert this into another key of the same length?  Is a derivative hash in some way stronger?

Obviously if a password was shorter than the intended key-length, or if the password was predictable (ie, memorizable), I can see how a KDF would be useful. But given the above circumstances, I reason that a KDF (like BCrypt of PBKDF2) would actually reduce the character-range of the key (to 64 chars in bcrypt, and 16 chars in PBKDF2), effectively increasing the chance of a brute-force attack (however unlikely).  Any insights?
The point of a KDF is to take a low-entropy input and significantly increase the amount of computational power (and thus time or cost) it requires to brute-force, hopefully to a level on-par with a truly random value.

If you're already using a 256-bit value generated from a CSPRNG, there is no need to use a KDF.

In fact, using a KDF can only reduce the security of your keys. If there are any collisions in your hash function for 256-bit inputs, the number of possible KDF-generated keys will be fewer than the number of inputs, and you have a smaller possible keyspace. On the other hand, it can't possibly increase security, because if you're using a KDF to expensively turn 256-bit keys into different 256-bit keys, attackers have no need to go through the KDF. They can just enumerate the 256-bit keyspace in the first place.