The benefit of PBKDF2 for big keyfile? The man page of cryptsetup says:


  Whenever a passphrase is added to a LUKS header (luksAddKey,
  luksFormat), the user may specify how much the time the passphrase
  processing should consume. The time is used to determine the iteration
  count for PBKDF2 and higher times will offer better protection for
  low-entropy passphrases, but open will take longer to complete. For
  passphrases that have entropy higher than the used key length, higher
  iteration times will not increase security.


Does it mean that a binary keyfile of more than 64 random bytes (each having 8 bits of entropy?) is useless with PBKDF2 and a hash of 512 bits like SHA-512? The cost of testing all the hashes directly being cheaper than testing all the keyfiles.

Does it also mean that reducing the iteration time to 1 millisecond (or just to 1 iteration if it's even possible?) for such a keyfile doesn't affect the security?

And finally does it mean that using PBKDF2 with such a big keyfile, by reducing its size to just 512 bits, actually lower the security of a LUKS header?
Does it mean that a binary keyfile of more than 64 random bytes (each having 8 bits of entropy?) is useless with PBKDF2 and a hash of 512 bits like SHA-512? The cost of testing all the hashes directly being cheaper than testing all the keyfiles.


Yes, it does. After 128 to about 256 bits security the amount of security provided by the bits alone doesn't make sense anymore (impossible is impossible).


  Does it also mean that reducing the iteration time to 1 millisecond (or just to 1 iteration if it's even possible?) for such a keyfile doesn't affect the security?


Yes, if the input does indeed have that much entropy (and is therefore not really a usable password or passphrase), then you might as well perform one operation per ms. Or much faster.


  And finally does it mean that using PBKDF2 with such a big keyfile, by reducing its size to just 512 bits, actually lower the security of a LUKS header?


No, that's unlikely. The amount of information lost by performing many, many operations is still minimal, so you will probably maintain the security of the underlying HMAC.

Note that security proofs like salts. Removing the salt entirely may make the calculation - at least theoretically - less secure. So it is probably best to replace the password hash with e.g. HKDF, a key based key derivation function that optionally takes a salt.