LUKS header detaching

[parazyd]

Should we implement LUKS header detaching from freshly locked tombs? Should it be a default?

An option for storing the header could be keeping it in the tomb key itself.

[jaromil]

I am in favor of this as it would improve tomb's security and resilience, since one can more easily backup keys instead of the tomb and the integrity of headers is vital to access the tomb.

It is a rather delicate change that should be 100% retrocompatible with older tombs.

There will be the need to extend the range of information embedded "key header", which is right now sometimes present to specify pbkdf2 configuration. It will make keys bigger (up to 5Kb) which may impact qrcode generation and image steganography, while I'm not sure we should consider a compression algo for the 4Kb LUKS header (which alone is 4 times bigger than a key right now).

These are just some initial considerations for now, will follow up with more or organise this section better on a new edit. This change will go into Tomb 3, for which I'm creating a milestone.

[jaromil]

can you post a link here on that cryptsetup with deniable patch?

[parazyd]

It's this one: https://github.com/kriswebdev/cryptsetup-deluks

Keep in mind it's probably not been reviewed by anyone yet.

[rekahsoft]

I was about to create an issue for this. fwiw, I have used detached luks header (via the --header argument) which is available in modern version of luks these days. It definitely would be slick to be able to store a detached luks header in the keyfile itself. This would make it impossible to know that a tomb is even a tomb (deniable encryption).