Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
Original issue reported on code.google.com by
jo...@freesources.org
on 20 Jul 2009 at 1:29