decrypt_gpg keyscript fails due to trailing \n in key

Bug #363229 reported by Martin Unsal
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
New
Undecided
Unassigned
Nominated for Karmic by Martin Unsal

Bug Description

Binary package hint: cryptsetup

I use cryptsetup with a GPG key and passphrase. Worked fine in Gentoo but it seems to be deprecated in Ubuntu. At least, I gather that from the following in /lib/cryptsetup/scripts/decrypt_gpg:

---
echo "gpg decryption not implemented yet" >&2
exit 1
---

This is in Ubuntu 8.10 with cryptsetup 2:1.0.6-6ubuntu2.3.

I commented out these lines but there's a reason this is deprecated:

---
root@petn:~# cryptdisks_start crypt-backup-500
 * Starting crypto disk... * crypt-backup-500 (starting)
Performing GPG key decryption
Enter passphrase:
Command failed: No key available with this passphrase.
Performing GPG key decryption
Enter passphrase:
---

Here is the relevant line in my crypttab:

crypt-backup-500 /dev/sdg3 /root/key-int-backup.gpg luks,keyscript=/lib/cryptsetup/scripts/decrypt_gpg

This has been bugging me for years so I think I have tracked down the problem.

1) /usr/bin/gpg -q --decrypt leaves a trailing \n at the end of the key string on stdout
2) /lib/cryptsetup/cryptdisks.functions uses the cmd line parameter "--key-file=-" to cryptsetup
3) this command line parameter will not accept a trailing \n, whereas the default behaviour of cryptsetup (which also reads key file from stdin) will discard the trailing '\n'

Here is the smoking gun:

---
root@petn:~# gpg -q --decrypt /root/key-int-backup.gpg | cryptsetup --key-file=- luksOpen /dev/sdg3 crypt-backup-500
Enter passphrase:
Command failed: No key available with this passphrase.
root@petn:~# gpg -q --decrypt /root/key-int-backup.gpg | cryptsetup luksOpen /dev/sdg3 crypt-backup-500
Enter passphrase:
key slot 0 unlocked.
Command successful.
root@petn:~# cryptsetup luksClose crypt-backup-500
root@petn:~# gpg -q --decrypt /root/key-int-backup.gpg | tr -d \\n | cryptsetup --key-file=- luksOpen /dev/sdg3 crypt-backup-500
Enter passphrase:
key slot 0 unlocked.
Command successful.
root@petn:~#
--

Here are a few ways to fix this, in order from best to worst (my opinion):

1) Fix cryptsetup so that --key-file=- command line parameter discards trailing \n's.
2) Make cryptdisks.functions avoid the --key-file=- idiom, instead just skip --key-file if key is stdin.
3) The following horrible hack in /lib/cryptsetup/scripts/decrypt_gpg:

---
 echo "Performing GPG key decryption" >&2
# if /usr/bin/gpg -q --decrypt $key; then
 if /usr/bin/gpg -q --decrypt $key | /usr/bin/tr -d \\n; then
---

Can someone choose one of these fixes and implement it? I'm not an ubuntu developer...

Thanks,
Martin

Revision history for this message
mejo (jonas-freesources) wrote :

hey martin,

this bug is not reproducible with recent cryptsetup (1.0.7). actually it's the other way round:

# dd if=/dev/urandom of=testkey1 bs=1 count=512
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.00259551 s, 197 kB/s
# gpg -o testkey1.gpg -r test --encrypt testkey1
# cryptsetup luksFormat /dev/vg_int/ctest_key testkey1
Command successful.
# cryptsetup --key-file=testkey1 luksOpen /dev/vg_int/ctest_key ctest_key
key slot 0 unlocked.
Command successful.
# cryptsetup luksClose ctest_key

# gpg -q --decrypt testkey1.gpg | cryptsetup --key-file=- luksOpen /dev/vg_int/ctest_key ctest_key

You need a passphrase to unlock the secret key for
user: "test test (test) <email address hidden>"
2048-bit ELG-E key, ID F3927D08, created 2009-09-01 (main key ID 3D18A229)

key slot 0 unlocked.
Command successful.
# cryptsetup luksClose ctest_key

# gpg -q --decrypt testkey1.gpg | cryptsetup luksOpen /dev/vg_int/ctest_key ctest_key

You need a passphrase to unlock the secret key for
user: "test test (test) <email address hidden>"
2048-bit ELG-E key, ID F3927D08, created 2009-09-01 (main key ID 3D18A229)

Command failed: No key available with this passphrase.

i suggest you to re-encrypt the keyfile with gnupg. which cryptsetup version do you use?

greetings,
 jonas

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.