To make LUKS detached header even more secure?

Dear LUKS Creators,

First of all, thank you very much for creating the powerful LUKS
program. Please accept  my deepest gratitude for your great works.

I have an enquiry about the volume master key and the keyslot digest.
And also a security aspect discussion on a detached header setup.

1. How are the volume master key and the keyslot digest generated?

I have skimmed through the source code. Please correct me if I am
wrong. I thought the volume masker key was generated from the
passphrase/the keyfile. But I found out that the volume master key is
actually generated by random, at /lib/volumekey.c line 141 in
crypt_generate_volume_key() -
https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/lib/volumekey.c#L141
. This makes sense because LUKS enables us to specify the
--master-key-file directly. If MK is not generated independent to the
passphrase, we have to work reversely from MK and passphrase to obtain
the keyslot digest.

For the keyslot digest, I guess it is generated at
/lib/luks2/luks2_digest.c line 85 from LUKS2_digest_find_free() -
https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/lib/luks2/luks2_digest.c#L85
. But I cannot trace any further as I cannot find the function body of
json_object_object_get_ex().

2. To achieve an even more secure design than the LUKS2 detached header?

With the header detached onto the USB Key, and volume locked with an
user passphrase, it is so-called a two-factor authentication setup.
However I find a weakness scenario in this setup. An attacker who
gains a clone of the USB Key can start his attack, without the need to
wait for an acquisition of encrypted disk. This weakness is mainly
because, with solely the header, we can verify if our passphrase is
correct.

IF the volume master key is generated from the user passphrase, please
consider another setup. Stored in the USB Key are the hashing options
(like PBKDF=argon2id, iteration cost=19, memory cost=4G, thread
cost=4) and also the salt. This is basically the LUKS2 header without
the digest. Using the passphrase, the salt, and the PBKDF options, we
can generate the volume master key as usual. However, there is no way
for the attacker to verify if the passphrase is correct. Until the
attacker obtains both the USB Key and the encrypted disk, he can
verify if the guessed volume master key reveals meaningful bytes (e.g.
by file system signatures) from the disk.

My suggested setup has its drawbacks. It cannot support multiple keys
obviously. If we store two sets of hashing options and salts in the
USB Key, the attacker will be able to verify if his guesses of the
volume master keys match.

However it is possible to change the user passphrase without
re-encryption. The setup needs to be tweaked a bit. Similarly we use
the user passphrase, hashing options, and the salt to generate a MK1.
With this MK1, we generate a series of random bits (MK). This series
of random bits is actually the volume master key (MK). MK will never
be stored plainly on the USB Key. Instead, the encrypted version,
encrypt(MK1, MK), is stored on the USB Key. Upon passphrase change, we
generate MK2 with the new passphrase, new hashing options, and new
salt. With MK1 also unlocked, we simply copy the MK to the new MK2's
container. Then another encrypted version, encrypt(MK2, MK), is stored
on the USB Key. This is very similar to the LUKS keyslot digests.
However, with only one set of hashing options and salt present in the
USB Key, the attacker is still impossible to verify his guesses of the
MK.

I would like to point out that this suggested setup is stronger than
using LUKS plain mode. It is because it inherits the same passphrase
hashing, with salting, and also AF diffusion. It performs everything
as what LUKS2 does. It intentionally drops the ability to store
multiple keys. In return, an attacker who gets only the USB Key (i.e.
the header) will not be able to start passphrase hacking.

In fact LUKS is already very secure, in addition to very convenient.
IF we can disable passphrase checking in the LUKS header, we can
tighten the security of a detached header setup even further.

Thank you very much for your time. Hope you are doing well everyday.

Best wishes,
midnite