method to change the hash per-slot

[GoogleCodeExporter]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537385

The "hash spec" reported in the luksDump output should be changeable
for an existing volume. After all, it should apply only to existing
slots and should thus be a per-slot value, with a default for new
slots. It would be nice if I could change hashes by creating a new
key/slot with the new hash and removing the old slot to get rid of
the old hash.

http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3296

(bug reported by Martin F. Krafft <madduck@debian.org>)

Original issue reported on code.google.com by jo...@freesources.org on 20 Jul 2009 at 1:29

[GoogleCodeExporter]

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?

Original comment by gmazyl...@gmail.com on 20 Jul 2009 at 7:38

[GoogleCodeExporter]

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

Original comment by jo...@freesources.org on 21 Jul 2009 at 10:15

[GoogleCodeExporter]

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.

Original comment by gmazyl...@gmail.com on 30 Jul 2009 at 3:12

• Changed state: Started

[GoogleCodeExporter]

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 :(

Original comment by franxisc...@gmail.com on 5 Jan 2010 at 3:05

[GoogleCodeExporter]

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?

Original comment by mmk...@gmail.com on 11 Jul 2010 at 8:04