Re: To make LUKS detached header even more secure?

Dear Michael Kjörling,

Thank you very much for your prompt reply. You have given me a better
insight of LUKS.

> So, if I understand correctly, what you are proposing is basically a
> _split_ header, with part of the data stored in one location and part
> of the data stored in another location, and one (but not both) of
> those partial headers possibly detached from the container?

My apologies that I did not present my suggested setups clearly. Let
me explain by the pseudo code which I copied from the LUKS1
specification.
https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/LUKS_docs/on-disk-format.pdf

In the partition header, during creation:

(C1) phdr.mk−digest =
PBKDF2( masterKey , phdr.mk−digest−salt , phdr.mk−digest−iter ,
LUKS_DIGESTSIZE )

In each keyslot, during creation:

(C2) pwd−PBKDF2ed =
PBKDF2( password , ks.salt , ks.iteration−count , masterKeyLength )

(C3) splitKey =
AFsplit( masterKey , masterKeyLength , ks.stripes )

(C4) encryptedKey =
encrypt( phdr.cipherSpec , pwd−PBKDF2ed , splitKey , splitKeyLength )

In each keyslot, during decryption:

(D2) pwd−PBKDF2ed =
PBKDF2( password , ks.salt , ks.iteration−count , masterKeyLength )

(D4) splitKey =
decrypt( phdr.cipherSpec , pwd−PBKDF2ed , encryptedKey , encryptedKeyLength )

(D3) masterKeyCandidate =
AFmerge( splitKey , masterkeyLength , ks.stripes )

During decryption, check against the MK digest:

(D1) MKCandidate−PBKDF2ed =
PBKDF2( masterKeyCandidate , phdr.mk−digest−salt , phdr.mk−digest−iter
, LUKS_DIGESTSIZE )

As I am far from a professional in cryptography, I aim to replicate
the algorithms of LUKS, hoping to achieve the same level of
cryptographic strength. From the above, the phdr.mk−digest (C1), hence
the first (C1) and the last operations (D1), are unnecessary for the
MK encryption and the MK decryption. My proposed design is just DO NOT
STORE phdr.mk−digest in the header. This leads to a problem that we
cannot verify the masterKeyCandidate (D3). But it can avoid hacking
solely on the header.

> (Detached header) No, that is not proper 2FA. As is clearly demonstrated by your
> argument about how the second storage device can be copied (and
> relatively easily, at that), both are "something you know".

I would like to point out that, even if the detached header is in the
hand of another person who does not know the passphrase, an attacker
who acquired the detached header is sufficient to start the cracking.
It is identical to the non-detached header scenario. The attacker is
just yet to obtain the actual data. Given that (as far as I can find)
no security advice on the Internet which encourages re-encryption of
the entire volume on a regular basis, the data is at plain risk until
the hard disk dies. In which, a patient attacker can have 3 to 5 more
years to work on cracking.

P.S. I do re-encryption regularly.

> You claim increased resistance to passphrase guessing by an attacker
> who has access to the detached header but not the encrypted (locked)
> container itself, but there's already a simple way to do that:
> increase iteration count, passphrase length, or both.

I do agree that the current LUKS, with the contemporary hashes, is
already very strong. But the strengths of encryption algorithms depend
mostly on the speed of processing power. It is strong today. It may be
breakable next year.

In my proposed design, an attacker can do nothing if he gets the
header. If an attacker gets the encrypted disk, he can hack on the MK,
the tough way. Only when an attacker gets BOTH the header and the
encrypted disk, then he can start a normal cryptographic attack.

One more point to note in real life scenarios, users tend to have
multiple copies (the need of backups) of the header USB Keys carrying
around, to the office, to the cafe, etc. It is a lot easier to get a
clone of the header without the users' awareness. On the contrary,
cloning the encrypted disks usually involve breaking into premises and
take longer times.

> Since this would be aimed only or primarily at
> users who use a detached header stored on a separate device, who seem
> likely to already care more about security than the average user, I
> don't think either is an unreasonable assumption.
> ...
> None of this is to say that the security of LUKS couldn't _possibly_
> be improved upon somehow (such a claim would be naiive), but there's
> ample reason already to not add complexity based on what appears at
> least to me to be a rather contrived threat model.

I do agree that there is not an urge to update the current LUKS. I do
like a quote from the FAQ, " It is better to have less protection
against low-entropy passphrases and ***people actually use LUKS, than
having them do without encryption altogether.*** ". Convenience plays
an important role in the real world too.

Thank you again for your informative reply. It is my pleasure to
discuss the concepts with you. In the future, I will fork the project
for a few paranoids like me.

Best regards,
midnite