Q:

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?

A:

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.

A:

Take the following points into consideration:

A 32 character password composed of 95 ASCII characters only has $\log95^{32}\approx 210$ bits.
As long as there are no quantum computers (which would reduce the key strength to 105 bits), that's not a practical problem.
Not taking the previous point into account, if your password really gets generated randomly, there's no need for a KDF.
However, if the password is user-provided, it usually has low entropy and a good KDF can make a brute-force attack much more difficult.
If only 192 bits of security are required, AES-192 could be used.
Although a KDF will take some time to derive the key, AES-192 w/KDF will still be faster for large messages.
Bcrypt was originally designed as a deliberately slow has function, not a key derivation function. This explains the "limited" output (448 bits).
PBKDF2 can generate keys of arbitrary length.
The fact that specific implementations of Bcrypt and PBKDF2 use Base64 and hexadecimal encoding doesn't mean that the algorithms are limited to that.
If the possible encodings of the KDF (output) and the cipher (key input) do not match, there's always conversion.
Memory-intensive KDFs such as Scrypt use large amounts of memory in addition to processor powers, making parallelization more expensive.

