Do PBKDF2 keys generated at a lower iteration count leak information? Assume the threat model here is that the server is not to be trusted and the client is trusted. A user registers for an account and the client chooses an iteration count of 50,000 to generate a 512 bit key for the user.

The key is then split in half: the first half is kept locally as the encryption key, and the second half is sent to the server as the user's "password".

key = pbkdf2(password: inputted_password, salt: some_salt, cost: 50000, size: 512)
encryption_key = key.first_half
server_password = key.second_half


server_password is sent to the server to authenticate.

Assume now that on some subsequent login session, the client is tricked by some irrelevant means into computing server_password using a lower iteration count of 3,000 instead of the real value of 50,000.

So the client is tricked into using a lower cost:

key = pbkdf2(password: inputted_password, salt: some_salt, cost: 3000, size: 512)
server_password = key.second_half


and this server_password is sent to the server.

My question is, does this "weaker" derived password leak any information to the server on what the nature of the user's original inputted password is?
Knowledge of server_password computed with 3,000 iterations instead of 50,000 makes it over 16 times faster to brute-force inputted_password and find encryption_key than was otherwise possible.

server_password can take much more values ($2^{256}$) than inputted_password can be tested, and PBKDF2 behaves like a random function, thus the first inputted_password found matching (if any) is the true one with overwhelming certainty.

Having found inputted_password, the adversary computes encryption_key by applying the same relatively low cost technique that generated it in the first place. That also allows to check that inputted_password is right (that is, the user did not misskey while s/he was tricked to use a lower iteration count; but even if that was, that could be worked around by trying small variations).