[arch-projects] [initscripts][RFC] cryptsetup: deprecate old syntax and default to the systemd one
From: Tom Gundersen <teg@jklm.no> We detect if the old syntax is used, and if so print a warning and use the old parsing code. Otherwise, we pass everything on to systemd-cryptsetup. Similarly to what was done with the network syntax, we intend to keep the legacy stuff working for a long time. See crypttab(5) for the new syntax[0]. The main reason for this change, is to be closer to what other distros do. The systemd syntax is based on Debian's format, and is essentially what is being used by at least Debian, Ubuntu, Fedora and Suse. Such widespread use means that it will be better documented in non-Arch-specific documentation, and is more likely to see integration with third-party tools. It is also surely appreciated by admins who use more than one distro, that they don't have to know more than one config format for these sorts of basic things. Furthermore, by actually sharing the code with systemd we get to rely on their much more widespread testing and review compared to what we are able to do ourselves. This is particularly important for the encryption code, as it is the most obscure code in initscripts and any bugs in it would have potentially very severe consequences. Lastly, there are a few (albeit minor) issues I see with our current format: /etc/crypttab is not a plaintext file, but needs to be parsed through bash. The (deprecated) embedded passwords have been a source of problems in the past. And, there is no level of abstraction between the crypttab options and cryptsetup, we just pass them on blindly. The new format and the old one cover roughly the same usecases. To the best of my knowledge, the only use-case not (yet) supported by systemd-cryptsetup, is mounting a removable device and reading the key from a file on that device. For this, stick with the old syntax (though be careful, it is inherently racy). [0]: <http://0pointer.de/public/systemd-man/systemd.unit.html> (note that keyfile-offset support is coming in the next systemd version). --- functions | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 58 insertions(+), 4 deletions(-) diff --git a/functions b/functions index 16f8d8f..7fd5258 100644 --- a/functions +++ b/functions @@ -381,12 +381,13 @@ activate_vgs() { (( $? == 0 )) && stat_done || stat_fail } -do_unlock() { +do_unlock_legacy() { # $1 = requested name # $2 = source device # $3 = password # $4 = options stat_append "${1}.." + printf "${C_FAIL}Using legacy crypttab format. This will stop working in the future. See crypttab(5).${C_OTHER}\n" local open=create a=$1 b=$2 failed=0 # Ordering of options is different if you are using LUKS vs. not. # Use ugly swizzling to deal with it. @@ -448,7 +449,6 @@ do_unlock() { /*) cryptsetup -d "$3" $4 $open "$a" "$b" >/dev/null;; *) - printf "${C_FAIL}crypttab contains a literal encryption key. This will stop working in the future.${C_OTHER}\n" echo "$3" | cryptsetup $4 $open "$a" "$b" >/dev/null;; esac if (( $? )); then @@ -460,10 +460,64 @@ do_unlock() { return $failed } +do_unlock_systemd() { + stat_append "${1}.." + local failed=0 + if ! /usr/lib/systemd/systemd-cryptsetup attach "$1" "$2" "$3" $4; then + failed=1 + else + IFS=, + if in_array swap ${options[@]}; then + if ! mkswap /dev/mapper/$name >/dev/null; then + failed=1 + fi + elif in_array tmp ${options[@]}; then + if ! mke2fs /dev/mapper/$name >/dev/null; then + failed=1 + fi + fi + fi + if (( $failed )); then + stat_append "failed " + else + stat_append "ok " + fi + return $failed +} + +do_unlock() { + local name=$1 device=$2 password=$3 options=$4 + + if [[ ${options:0:2} =~ -. ]]; then + do_unlock_legacy "$name" "$device" "$password" "$options" + return $? + fi + + case $password in + ASK|SWAP) + do_unlock_legacy "$name" "$device" "$password" "$options" + ;; + /dev/*) + if [[ ${password##*:} == $password ]]; then + do_unlock_systemd "$name" "$device" "$password" "$options" + else + do_unlock_legacy "$name" "$device" "$password" "$options" + fi + ;; + /*|none|-) + do_unlock_systemd "$name" "$device" "$password" "$options" + ;; + *) + do_unlock_legacy "$name" "$device" "$password" "$options" + ;; + esac + return $? +} + read_crypttab() { # $1 = function to call with the split out line from the crypttab local line nspo failed=0 - while read line; do + while read line <&3; do [[ $line && $line != '#'* ]] || continue eval nspo=("${line%#*}") if $1 "${nspo[0]}" "${nspo[1]}" "${nspo[2]}" "${nspo[*]:3}"; then @@ -471,7 +525,7 @@ read_crypttab() { else failed=1 fi - done < /etc/crypttab + done 3< /etc/crypttab return $failed } -- 1.7.11.1
Am Wed, 11 Jul 2012 04:33:07 +0200 schrieb teg@jklm.no:
The new format and the old one cover roughly the same usecases. To the best of my knowledge, the only use-case not (yet) supported by systemd-cryptsetup, is mounting a removable device and reading the key from a file on that device. For this, stick with the old syntax (though be careful, it is inherently racy).
[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. Heiko
Heiko, On Wed, Jul 11, 2012 at 11:04 AM, Heiko Baums <lists@baums-on-web.de> 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 <teg@jklm.no>:
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."
Thanks. That clarifies it. Looks indeed a bit clearer than the old syntax. Heiko
Am Wed, 11 Jul 2012 11:13:27 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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
On Jul 28, 2012 7:18 AM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Wed, 11 Jul 2012 11:13:27 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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.
Could you please include the old and the new syntax you use so I can understand the problem?
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?
The key file is never written anywhere. Tom
Am Sat, 28 Jul 2012 13:02:38 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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
On Jul 28, 2012 3:36 PM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Sat, 28 Jul 2012 13:02:38 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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.
Please double check that the units are correct in your new file.
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 <teg@jklm.no>:
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
On Jul 28, 2012 5:38 PM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Sat, 28 Jul 2012 16:21:40 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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.
I think one of them should be in buys and one in bytes. I'm on my phone, so can't check.
Am Sat, 28 Jul 2012 17:46:57 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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
On Sat, Jul 28, 2012 at 6:31 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 28 Jul 2012 17:46:57 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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
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).
Am Sat, 28 Jul 2012 18:51:55 +0200 schrieb Jan Steffens <jan.steffens@gmail.com>:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/28/2012 07:09 PM, Heiko Baums wrote:
Am Sat, 28 Jul 2012 18:51:55 +0200 schrieb Jan Steffens <jan.steffens@gmail.com>:
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?
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. Greetings, Christoph -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQFCThAAoJEOGIwUZuUxpnuF4P/j5HEGN6Hb4xPrUmiFoMycpZ oZJ8jEmKFlZveqDFg3f9KAFPxtmgwOK8Wneb1DrBkqviiRqm71n4w/IXPuiFDXtF XtENAo9QAfIxdEZovBNeEid8v7npc1Xn5WnKHsZOTbdOqsl1gYqQCDNI/pdu9JLQ XW1Ipan9KtUEIN+vvA3vXJaa380i6RP6zsIoGfxbJrEk4yzSzIFn66dYwBsOrBlg /VYVs48PtO41F5mwKszTfyQ3zfMEsowFv+CbPAiZIRObka6MTn7eKno/TifnkYXF 6WKAVI/6bdPeoerRe2fjluZimOBiAzsjiSjIOLgkPzEDu8bdUi0SDmr6d5ot5OFu PfvjNeRHJq7KAil6BxbBW+g9SOUQ77bvhXDNowwurqtSV0uPAxrI5G17mBhoSzdG Bqi++11BLVbsMhhDmy+nt9ChN1ktZSDawDC6C80pxKg/4UAMRmk5Opf0d0yLUzsS yOTg42cz7sGQ6Ibcx5vtWBk3jrmrz534cxUhXyxx3Gt0tE27AvgJ9HARvPeepVwX j3/g1TvyQFdL9SyOwjH3A4af2RtQsR4PsmGPuyI0zht8/IVP5ylU2jL5hznHHMin wKaA4BL1hazgRXb3saHWNvUs/y9mTWx82147qZpfu0Ys9PKoGgvDOj4wt22YMJ9x DJEIinJhNr92L/6hRA7y =5g4a -----END PGP SIGNATURE-----
Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano <mail@cvigano.de>:
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
On Jul 28, 2012 8:53 PM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano <mail@cvigano.de>:
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
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. Tom
Am Sat, 28 Jul 2012 21:19:39 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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
On Sat, Jul 28, 2012 at 10:26 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 28 Jul 2012 21:19:39 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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.
libcryptsetup is used. I don't see why such an implementation detail should be
I read man crypttab, and I read man cryptsetup. And the cryptsetup parameter size has nothing to do with the key size.
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.
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.
That's the intention. There might of course be regressions, I'm looking into that now.
I mean we're not talking about a font or locale setting, we're talking about a harddisk encryption.
Keep your snarky comments to yourself. -t
Am Sat, 28 Jul 2012 22:45:01 +0200 schrieb Tom Gundersen <teg@jklm.no>:
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 Sat, Jul 28, 2012 at 11:18 PM, Heiko Baums <lists@baums-on-web.de> wrote:
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.
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. It might be possible to overload the size= parameter to do the job, but I don't think that's a good idea (especially as the units would differ depending on the use).
Keep your snarky comments to yourself.
Well, that depends.
No, it really does not. Everyone's just trying to help. -t
On Sun, Jul 29, 2012 at 12:09 AM, Tom Gundersen <teg@jklm.no> 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
Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano <mail@cvigano.de>:
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
On 07/28/2012 12:58 PM, Heiko Baums wrote:
Am Sat, 28 Jul 2012 19:44:01 +0200 schrieb Christoph Vigano <mail@cvigano.de>:
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.
<teg <at> jklm.no> writes:
From: Tom Gundersen <teg <at> jklm.no>
We detect if the old syntax is used, and if so print a warning and use the old parsing code. Otherwise, we pass everything on to systemd-cryptsetup. Similarly to what was done with the network syntax, we intend to keep the legacy stuff working for a long time.
See crypttab(5) for the new syntax[0].
The main reason for this change, is to be closer to what other distros do. The systemd syntax is based on Debian's format, and is essentially what is being used by at least Debian, Ubuntu, Fedora and Suse. Such widespread use means that it will be better documented in non-Arch-specific documentation, and is more likely to see integration with third-party tools. It is also surely appreciated by admins who use more than one distro, that they don't have to know more than one config format for these sorts of basic things.
Hi, there is other problem too: systemd-cryptsetup handles keyfile differently from cryptosetup itself on plain mode (without LUKS). I have some partitions encrypted using plain mode and the new crypttab syntax does not mount them due to the differences on handling keyfiles. I even fired a bug against systemd explaining the differences and asking for compatibility (https://bugs.freedesktop.org/show_bug.cgi?id=52630) So also for me, unfortunatelly the new syntax (and the usage of systemd-cryptosetup) is also a no-no. Best regards, Marcos
participants (7)
-
Christoph Vigano
-
Heiko Baums
-
Jan Steffens
-
Marcos Lenharo
-
Matthew Monaco
-
teg＠jklm.no
-
Tom Gundersen