method to change the hash per-slot about cryptsetup HOT 5 OPEN

In current LUKS on-disk header hash spec is common for all slots, in current 
code
only "sha1" is supported.

I have already patch which allow use all hashes provided by gcrypt for AF 
(specified
by -h during luksFormat).

The only problem is that in LUKS header is only 20 bytes (enough for sha1) 
reserved
for MK digest - so only first 20 bytes of final hash can be compared.

The hash definition per slot - maybe in LUKS2, definitely not possible with 
current
on-disk format.

But there will be soon possibility to "reformat" LUKS header with different 
hash, but
retaining the same volume key - this is problably enough, I guess?

Yes, I see that it isn't possible to have different hashs for key slots of the 
same
device, but at least that could be regarded as wishlist item for LUKS2.

And for the particular bugreport in debian I guess that the submitter is happy 
if he
can change the hash on the fly.

greetings,
 jonas

Devel code have now selection of hash for LUKS header, this fixes partially the 
problem.

I'll update the bug when other parts of problem are adressed.

All the ways I can think to solve the problem mean doing the system not 
backwards
compatible. Though I think this issue is obvious and unavoidable.

Anyway, if we want to keep a "backwards" compatible system for the rest of key 
slots
(Those using the same function as the rootkey) we could use a special value for 
the
active field and store the data in one of the anti-forensics" stripes.

The main problem is that I don't know how the active field is parsed and 
processed as
the behaviour is undefined when the active field doen't contain 0x0000DEAD nor
0x00AC71FE :(

gmazyland, Jul 20, 2009 said:
"The only problem is that in LUKS header is only 20 bytes (enough for sha1) 
reserved for MK digest - so only first 20 bytes of final hash can be compared."

That's disappointing, but I suppose it's unavoidable to maintain backwards 
compatibility.  So, if I select --hash sha512 during luksFormat, am I to 
understand that the sha512sum of the inflated master key is truncated to its 
first 20 bytes and saved as the MK Digest?  Is that right?

Will LUKS_DIGESTSIZE stay fixed at 20 bytes until LUKS2?