Heiko, On Wed, Jul 11, 2012 at 11:04 AM, Heiko Baums wrote:

...

[0]: http://0pointer.de/public/systemd-man/systemd.unit.html (note that keyfile-offset support is coming in the next systemd version). ---

Do you know what's about reading a key raw from a USB stick by dd? In the link you posted nothing is mentioned about cryptsetup.

Damn, I pasted the wrong link. Sorry about that. It should have been: http://0pointer.de/public/systemd-man/crypttab.html. So, to decrypt /dev/sda1 using a 1024 bits key stored at an offset of 1MB on the key usb drive /dev/sdd, you would do secret /dev/sda1 /dev/sdd size=1024,keyfile-offset=1024 The missing keyfile-offset entry from the link is: "keyfile-offset= Specifies the number of bytes to skip at the start of the keyfile; see cryptsetup(8) for possible values and the default value of this option." Cheers, Tom

Am Wed, 11 Jul 2012 11:13:27 +0200 schrieb Tom Gundersen :

Damn, I pasted the wrong link. Sorry about that. It should have been: http://0pointer.de/public/systemd-man/crypttab.html.

So, to decrypt /dev/sda1 using a 1024 bits key stored at an offset of 1MB on the key usb drive /dev/sdd, you would do

secret /dev/sda1 /dev/sdd size=1024,keyfile-offset=1024

The missing keyfile-offset entry from the link is:

"keyfile-offset= Specifies the number of bytes to skip at the start of the keyfile; see cryptsetup(8) for possible values and the default value of this option."

Now that the new initscripts are in [core], this new syntax doesn't work. I transfered the same values from my old crypttab syntax into the new one and all I get is this message: Unlocking home Failed to activate: Invalid argument Unlocking of home failed. The same for any other LUKS container except for / of course. After that it tries to mount the filesystems in these containers and falls into the maintenance prompt, because it obviously can't find those filesystems. Well, a fallback to a prompt for entering a password manually is missing in initscripts, too, but initscripts booted at least into the / partition, so that the other containers could be opened and the filesystems could be mounted manually. The old syntax works without any problems. Instead of /dev/sdd in your example I took /dev/usbkey which is a symlink set by a udev rule written by me. There's no partition on the USB stick and the USB stick is fully written with random characters. So the key must be read by dd with exactly those values as it is done by the initscripts. Removing the red warning, that the old syntax is used, would probably be good, and a feedback after the containers are successfully opened would also be nice like it was before. Btw., how does systemd-cryptsetup handle the keyfile? Where is it written and is it being overwritten after it is used to unlock the container as it is done by initscripts? Heiko

Am Sat, 28 Jul 2012 13:02:38 +0200 schrieb Tom Gundersen :

Could you please include the old and the new syntax you use so I can understand the problem?

The old syntax: home /dev/sdaX /dev/usbkey:15675879:1024 The new syntax: home /dev/sdaX /dev/usbkey size=1024,keyfile-offset=15675879 The old syntax and the cryptsetup handling of initscripts, most part of which I have written, btw., just works. The new syntax and the cryptsetup handling of systemd does not. See the /dev*) part in do_unlock_legacy(), and there particularly the *) part. This is what I need.

The key file is never written anywhere.

Are you sure? How is the key read and passed to cryptsetup? This usually has to be done by entering the password manually or by passing a key file. So if a key is read by dd it has to be written to a temporary file, which then can passed to cryptsetup. And for security reasons this temp file should first be overwritten and then deleted directly after the container is opened. Heiko

Am Sat, 28 Jul 2012 16:21:40 +0200 schrieb Tom Gundersen :

Please double check that the units are correct in your new file.

You mean the values? I already did that more than twice. I copied them with gpm anyway. They are absolutely correct. Heiko

Am Sat, 28 Jul 2012 17:46:57 +0200 schrieb Tom Gundersen :

I think one of them should be in buys and one in bytes. I'm on my phone, so can't check.

If they are directly passed to dd and cryptsetup then not. With the old syntax the same values are directly passed to dd and cryptsetup. See do_unlock_legacy(). So those values are absolutely correct, because the same values work and have ever worked with the old syntax. So there must be a bug in either the new part of initscripts or in systemd-cryptsetup. And I wouldn't wonder if it's systemd, because I know that my script works. Heiko

Am Sat, 28 Jul 2012 18:51:55 +0200 schrieb Jan Steffens :

size= is key size, NOT keyfile size.

It seems systemd's crypttab currently has no means of specifying keyfile size, so it will always try to read the maximum (up to 8MB according to cryptsetup --help).

And what is the difference between the keyfile size and the key size? The keyfile is the key. Btw., there's no file on the USB stick. The USB stick is just filled with random characters, which have to be read raw by dd. So the keyfile size is the same as the key size, and dd has to know how many bytes it has to read. Like I said, look at do_unlock_legacy() in /etc/rc.d/functions. Heiko

Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano :

According to crypttab(5): "size= Specifies the key size in bits; see cryptsetup(8) for possible values and the default value of this option."

As it is custom in cryptography, key sizes are given in bits, like RSA 4096 which means the key is 512 bytes long.

If your former size argument was given in bytes, convert that number to bits and try again.

But you don't want to tell me, that Lennart Poettering also has written his own dd. If this was really the case then I definitively would call him mad. But if the new systemd-cryptsetup is using dd then size wouldn't need to be in bits. I'll try it anyway. Heiko

Am Sat, 28 Jul 2012 21:19:39 +0200 schrieb Tom Gundersen :

Just read three man page please, it is documented there. From my memory, size is in bits and offset in bytes.

dd is not used. The key is not written to a temporary file, but libcryptsetup reads the relevant portion of the file/device directly.

So what is used or how does it work then? If you make such wide-ranging and important changes, you probably should document or explain it a bit more precisely, maybe also in the form of a news announcement. I read man crypttab, and I read man cryptsetup. And the cryptsetup parameter size has nothing to do with the key size. So which other documentation shall I read? You mentioned when you introduced the syntax change, that only the syntax is changed. So I must assume that everything else remains at it was. I mean we're not talking about a font or locale setting, we're talking about a harddisk encryption. Heiko

Am Sat, 28 Jul 2012 22:45:01 +0200 schrieb Tom Gundersen :

I was referring to the crypttab page. As I said, I didn't have the chance to double check this myself, but I noticed that your units were off, so that would at least be the first thing to check.

And I already answered that I checked it more than twice. Of course, I, too, can sometimes miss a detail when reading a man page.

That's the intention. There might of course be regressions, I'm looking into that now.

So, it was a bug or at least something that should be fixed if the size has to be converted from byte to bit.

Keep your snarky comments to yourself.

Well, that depends. If people don't seem to take me seriously and tell me to read 3 man pages even if I did it, then people have to live with such snarky comments. I know those comments didn't come only from you personally, but some of them did. And I didn't miss that you're on your phone, so I don't expect you to test and to fix this at once on your phone. I'm really willing to help and to test. But then this should be kept serious and factual. Nevertheless, I tried to convert the size from byte to bit in the new syntax. From the old syntax: home /dev/sdaX /dev/usbkey:15675879:1024 To the new syntax: home /dev/sdaX /dev/usbkey size=8192,keyfile-offset=15675879 Still the same error: Unlocking home Failed to activate: Invalid argument Unlocking of home failed. So the units are not the reason. Heiko

On Sun, Jul 29, 2012 at 12:09 AM, Tom Gundersen wrote:

Thanks to Heiko for bringing this up, and everyone else for their helpful comments. I think I now understand the situation. This is, as far as I can tell, not a bug. However, contrary to what I thought, this use-case is not yet covered by the new format.

This has been said by others, but just to make sure I get this right:

The size= parameter gives the key size in bits, and there is no parameter to specify the keyfile size.

When using PLAIN encryption, the keyfile size (in bytes) is calculated from the key size. However, on LUKS encryption this is (obviously) not possible, which is what I had not noticed until now.

I suspect that what we need to do is to add a keyfile-size= parameter.

FYI, this was just added upstream: http://lists.freedesktop.org/archives/systemd-devel/2012-August/006099.html. -t

On 07/28/2012 12:58 PM, Heiko Baums wrote:

Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano :

...

According to crypttab(5): "size= Specifies the key size in bits; see cryptsetup(8) for possible values and the default value of this option."

As it is custom in cryptography, key sizes are given in bits, like RSA 4096 which means the key is 512 bytes long.

If your former size argument was given in bytes, convert that number to bits and try again.

Btw., I read over it, you mentioned man cryptsetup. I guess you're mixing up two different things. The cryptsetup parameter size is something completely different and has nothing to do with the key size and with this issue.

We're talking here about the key size, that is how many bits or bytes have to be read raw from an USB stick. So we're talking here about the dd parameters skip and count.

Heiko

This is really annoying, but the original Debian format for crypttab uses "size" to correspond to --keyfile-size. It would be nice if systemd changed this so all of the options correspond one-to-one. To make matters worse, the variable name in the source code of sysd that stores this param is called "key_size," which is an entirely different option to cryptsetup altogether! For the legacy format of <dev>:<offset>:<length> the corresponding options are --keyfile-offset and --keyfile-size, so in crypttab you want keyfile-offset=<bytes>,size=<bytes>. In summary all of these options are: --keyfile-offset, keyfile-offset= Number of bytes to skip before reading from key-file --keyfile-size, size= Number of bytes to read from key-file --size, (not available in crypttab) The number of 512-byte sectors of the mapped block device, defaults to all available space from the underlying device, and does not apply to mapping a LUKS volume. --offset, (not available in crypttab) Similar to --size, number of 512-byte sectors to skip from the underlying block device before mapping. There is also --skip which is similar but has some subtle differences. --key-size, (not available in crypttab) Number of bits -- must be a multiple of 8 -- of the internal key used for the cipher Stream-of-conscience... it looks like systemd-cryptsetup might use size= for both --key-size and --keyfile-size. I'm currently trying to figure out what the difference between crypt_activate_by_volume_key() and crypt_activate_by_keyfile are. IIRC that former might be for reading from stdin, which is handled differently than reading a file or a password interactively.