keyfile-offset ignored (again?)

[GoogleCodeExporter]

# cryptsetup --cipher aes-xts-plain64 --offset 0 --key-file=/dev/sdb 
--keyfile-offset 32768 --key-size=512 open --type=plain /dev/sda1 enc 
results in
Ignoring keyfile offset and size options, keyfile read size is always the same 
as encryption key size.

This is extemely inconvinient. Why did you decide that the options like "using 
a block device to store raw key data" and "using offset" were just too stupid 
and must be dropped?

The first option was usable to store a key without need to load filesystem 
modules and with significantly less risk of the key data to be corrupted or 
compromised by some app inside the OS. 

The second one is necessary if you want to avoid crossing with MBR, which can 
easily be corrupted/overwritten/"fixed".

And in some cases like booting up in a complicated environment you can't even 
use utilities like dd to override this issue. So please, better bring this 
option back.

I've found a bugreport #125 
https://code.google.com/p/cryptsetup/issues/detail?id=125 here about this issue 
and it's marked at "fixed". But in the current Debian "testing" using 
cryptsetup v.2:1.6.6-4 , this problem remains.

Original issue reported on code.google.com by codepl...@gmail.com on 28 Jan 2015 at 9:44

[GoogleCodeExporter]

> Why did you decide that the options like "using a block device to store raw 
key data"
> and "using offset" were just too stupid and must be dropped?

Could you please point me to the information from which you concluded that this 
option was *dropped*? Cryptsetup has very strict backward compatibility policy.

The problem is that keyfile processing in LUKS and plain device types are 
completely different. The issue#125 you are referencing added offset support 
for LUKS but not for plain devices. (Previously there was not keyfile offset 
support at all.)

The keyfile-size does not make sense here (in plain mode you are reading always 
the key directly, so keys-size does the job).

But the keyfile-offset for plain device could be useful but it was never 
implemented.
So the question is if we should add it now...

Original comment by gmazyl...@gmail.com on 29 Jan 2015 at 7:46

[GoogleCodeExporter]

I cannot speak for the reporter, but you could assume s/he could have concluded 
it was dropped from the results in trying to apply them. 

>The keyfile-size does not make sense here (in plain mode you are reading 
always the >key directly, so keys-size does the job).

Well, the same argument you use for a "keyfile-offset" holds for 
"keyfile-size": both give you flexibility in ensuring an attacker who gains the 
keyfile itself cannot apply it without the exact parameters. Assume you have a 
16kB keyfile and use a non-maximum keyfile-size, this adds considerable 
guesswork without knowing whether the key is, e.g. 2048 bytes or whatever. Just 
the same as the offset does. 

>But the keyfile-offset for plain device could be useful but it was never 
>implemented.
>So the question is if we should add it now...

I do not want to vouch in either direction as I do not know the effort 
involved. There are workarounds like using an initramfs to handle keyfile 
processing before it is used to open the blockdevice. 

But in any case I am surprised to read it was never implemented, because the 
manpage has been clearly stating these options exist for plain mode for many 
releases...

Original comment by randomic...@gmail.com on 8 Feb 2015 at 6:41

[GoogleCodeExporter]

The problem was just the was never finished for plain devices (TBH I do not 
remember the real reason... :-)

Should be fixed now in commit
https://code.google.com/p/cryptsetup/source/detail?r=31a4d552a2d9ab6c0a365401692
6987c06628101#

Thanks.

Original comment by gmazyl...@gmail.com on 23 Feb 2015 at 9:43

• Changed state: Fixed