PBKDF2 對大密鑰文件的好處？
cryptsetup 的手冊頁說：
每當將密碼片語添加到 LUKS 標頭（luksAddKey、luksFormat）時，使用者可以指定密碼片語處理應消耗的時間。該時間用於確定 PBKDF2 的迭代計數，更高的時間將為低熵密碼提供更好的保護，但打開將需要更長的時間才能完成。對於熵高於使用的密鑰長度的密碼片語，更高的迭代時間不會增加安全性。
這是否意味著超過 64 個隨機字節（每個都有 8 位熵？）的二進制密鑰文件對於 PBKDF2 和 512 位散列（如 SHA-512）是無用的？直接測試所有雜湊的成本比測試所有密鑰文件便宜。
這是否也意味著將這樣的密鑰文件的迭代時間減少到 1 毫秒（或者如果可能的話，只減少 1 次迭代？）不會影響安全性？
最後，這是否意味著將 PBKDF2 與如此大的密鑰文件一起使用，通過將其大小減少到僅 512 位，實際上會降低 LUKS 標頭的安全性？
這是否意味著超過 64 個隨機字節（每個都有 8 位熵？）的二進制密鑰文件對於 PBKDF2 和 512 位散列（如 SHA-512）是無用的？直接測試所有雜湊的成本比測試所有密鑰文件便宜。
是的，它確實。在 128 到大約 256 位安全之後，僅由位提供的安全量不再有意義（不可能是不可能的）。
這是否也意味著將這樣的密鑰文件的迭代時間減少到 1 毫秒（或者如果可能的話，只減少 1 次迭代？）不會影響安全性？
是的，如果輸入確實有那麼多熵（因此不是真正可用的密碼或密碼），那麼您不妨每毫秒執行一次操作。或者更快。
最後，這是否意味著將 PBKDF2 與如此大的密鑰文件一起使用，通過將其大小減少到僅 512 位，實際上會降低 LUKS 標頭的安全性？
不，這不太可能。執行很多很多操作所失去的資訊量仍然很少，因此您可能會維護底層 HMAC 的安全性。
請注意，安全證明就像鹽一樣。完全去除鹽可能會使計算 - 至少在理論上 - 不太安全。因此，最好將密碼雜湊替換為例如 HKDF，這是一個基於密鑰的密鑰派生函式，可以選擇使用鹽。