That's quite a funny idea. LUKS2 really should do this by default when creating the empty slots when the disk is initialized first time. The used slots will be overwritten by passphrases, but these other slots would be indistingishable and would waste the attacker's time.

It would make typoing the password annoying for legitimate users too, so it wouldn't be good to enable it by default.

With weak (fast) parameters for the KDFs on the decoy passwords, I don't see how it would be annoying?

Doesn't that just give the attacker more targets to hit?

I know that under normal circumstances you can just write off the wildly improbable case of a hash collision, but when you're up against an army of GPU's I'm not sure I'd want to risk the possibility that `aaa` (or some other brute force candidate) collides with whatever urandom spit out that day.

Each of those red-herring passphrases is 384 bits. Enough said.

Even under abnormal circumstances, it can be written off. You're more likely to win several lottery jackpots in a row than to be bitten by that.

If you've got a TPM to leverage, this is essentially actually what systemd-cryptenroll --tpm2* does. Generate a large, cryptographically-secure key and pair it with PBKDF2 with 1000 iterations. Seal that random value in the TPM with optional PIN.

If used, the PIN itself can just be your prior disk encryption passphrase, and now you have the same PW entropy as before with additional protection against PCR modifications and brute-forcing via the TPM