Should try given password for next partition

I too would be interested in seeing this functionality added.

Since there is an approved blueprint this should be confirmed.

With usplash it is pretty easy to implement. However the problem is that it will work with usplash and usplash only. If you disable usplash its behaviour will still be the same. The problem is that without usplash the cryptsetup binary is fetching the password from console directly - leaving no chance to buffer it in an environment variable. However since most people will use usplash, it will at least fix it for them. Another unsolved issue is that not all entries from /etc/crypttab are handled by the initramfs but later in the bootprocess by /etc/init.d/cryptdisks-early & co. So one would probably need to move all entries from crypttab to initramfs.

The small fix described above: you have to modify /usr/share/initramfs-tools/scripts/local-top/cryptroot.
Here is a diff for hardy:

--- cryptroot.org 2008-05-28 21:52:56.000000000 +0200
+++ cryptroot 2008-05-28 23:09:02.000000000 +0200
@@ -191,8 +191,12 @@
    $cryptkeyscript $cryptkey < /dev/console 2> /dev/console | \
    $cryptcreate --key-file=- > /dev/console 2>&1
   elif [ -p /dev/.initramfs/usplash_outfifo ] && [ -x /sbin/usplash_write ]; then
- usplash_write "INPUTQUIET Enter password to unlock the disk ($crypttarget): "
- PASS="$(cat /dev/.initramfs/usplash_outfifo)"
+ if [ -z "$successful_pass" ]; then
+ usplash_write "INPUTQUIET Enter password to unlock the disk ($crypttarget): "
+ PASS="$(cat /dev/.initramfs/usplash_outfifo)"
+ else
+ PASS=$successful_pass
+ fi
    echo -n "$PASS" | $cryptcreate > /dev/null 2>&1
   else
    $cryptcreate < /dev/console > /dev/console 2>&1
@@ -200,12 +204,18 @@

   if [ $? -ne 0 ]; then
    echo "cryptsetup: cryptsetup failed, bad password or options?"
- sleep 3
+ if [ -n "$successful_pass" ]; then
+ unset successful_pass
+ count=$(( $count - 1 ))
+ else
+ sleep 3
+ fi
    continue
   elif [ ! -e "$NEWROOT" ]; then
    echo "cryptsetup: unknown error setting up device mapping"
    return 1
   elif [ -p /dev/.initramfs/usplash_outfifo ] && [ -x /sbin/usplash_write ]; then
+ export successful_pass=$PASS
    # clean the text, to give feedback that it worked
    usplash_write "TEXT-URGENT "
   fi

the is a reason for having two hooks: one for initramfs and one for the init script.
the initramfs hook is only for mounting the root filesystem. So the only point in the patch above is when you have your root device across several crypted lvm or raid volumes on different hard drives.

I think having a patch from cryptdisks doing the passphrase caching would make more sense.

IOW: I'm not at all convinced by that patch above, I'm sorry.

Well, the purpose of the initramfs script is not only to decrypt rootfs but also to decrypt an encrypted swap (which is necessary because you might wanna resume from suspend-to-disk).

Hi, i had a similar problem on my laptop:
* I have 2 encrypted partitions: sda5 and sda6:
   /dev/sda5 -> swap partition
   /dev/sda6 -> mapped to /var (with binding /var/home -> /home)
* Both partitions use the same password
* I use uswsusp for hibernate/resume features
* The initramfs step asks me for password at bootup: swap partition only
* Later the init script ask me again for the password of the /var partition

I think it makes sense to decrypt all filesystem in /etc/crypttab at the initramfs step.
Here is the patch I have tested on my laptop:
* it decrypts all /etc/crypttab partitions at initramfs stage
* it tries to unlock with same password all partitions.
* it works both with usplash and with console bootup

After doing the changes, execute "sudo update-initramfs -u"

I have the same issue with Jaunty.
Here is the script to try same password for next device.

You can patch the file in place, or copy the file to "/etc/initramfs-tools/scripts/local-top/" before to patch it: it will override the file in "/usr/share".
Then run "sudo update-initramfs -u".

--- /usr/share/initramfs-tools/scripts/local-top/cryptroot 2009-03-08 06:48:33.000000000 +0100
+++ /etc/initramfs-tools/scripts/local-top/cryptroot 2009-03-23 08:43:11.780028000 +0100
@@ -270,9 +270,18 @@
                        cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
                fi

+ if [ -n "$PASS" ]; then
+ # Try to unlock with previous password
+ message "Unlocking the disk $cryptsource ($crypttarget) using the same password"
+ else
+ # Ask for password
+ PASS=$(crypttarget="$crypttarget" cryptsource="$cryptsource" \
+ $cryptkeyscript "$cryptkey")
+ fi

- if ! crypttarget="$crypttarget" cryptsource="$cryptsource" \
- $cryptkeyscript "$cryptkey" | $cryptcreate --key-file=- ; then
+ if ! echo -n "$PASS" | $cryptcreate --key-file=- ; then
+ # Clear the wrong password
+ unset PASS
                        message "cryptsetup: cryptsetup failed, bad password or options?"
                        continue
                fi

The patched file.

And if you want to force decryption of all devices in "/etc/crypttab" during the "initramfs" stage, you can drop this additional file in the "hooks" folder.

Tested on Jaunty alpha.

Question: Does unsetting the PASS variable actually reset the bits in ram to zero-or do they stay set to the values the variable stored there until power is removed?

If unsetting the variable doesn't reset RAM bits to zero, I would suggest forcing them to an alternate value or to zero by resetting PASS to zer or a random number before unsetting it at the ehnd of the script.

For most applications it should be fine, I'm just wondering if an "expert" or NSA-grade attacker exploit this in some way in a power-on capture or online attack. I had a machine stolen by enemies who stormed my house-thankfully encrypted and shut off, so I think in these terms.

@Luke

I don't know the internals of the shell...
Maybe a function like this will help:

unset_pass()
{
        [ -n "$1" ] || return 0
        eval "$1=\$(dd if=/dev/urandom bs=1k count=4 2>/dev/null)"
        unset $1
        return 0
}

unset_pass PASS

Well, even with all the patches mentioned so far, you still have to type your password twice. A solution might be Novells approach on openSuSE 11.1: They add kernel options.

it goes like this:
$ cat /proc/cmdline
root=/dev/mapper/root luks_root=/dev/sda5
swap=/dev/mapper/swap luks_swap=/dev/sda2
home=/dev/mapper/home luks_home=/dev/sda6

Currently, ubuntu uses only root=. That's it. So So there is a script called cryptroot:
/usr/share/initramfs-tools/scripts/local-top/cryptroot

It should store the password in an environment variable and re-use it. Still, SuSEs approach is different, but it is also more complex and much uglier.

Hope that helps. Can some1 submit a patch?

Here is a solution I am using in Lucid and Maverick, when not using LVM so as to alllow use of separately encrypted partitions. This is to support multi-disk video editing machines. It is crude and uses hardcoded UUID values for each partition, not reading crypttab for now. Eventually I will play with making it use the crypttab values, but I was simply seeking a quick solution when I wrote this. I've been using this for months with no problems.

ALGORITHM:

Steps:

1: prompt for pasphrase, cache in a variable in ram (runs in initramfs, nothing should write to any disk)

   a: if plymouth is running, use plymouth ask-for-passphrase

2: unlock encrypted volumes-hard code these into script for now

3: if cryptsetup returns error, go back to 1.

4: forcibly reset the variable to a string of zeros

5: Delete the variable

6: exit

INITRAMFS SCRIPT: Name Cryptall, remove cryptroot in /usr/share/initramfs-tools/scripts/local-top

#!/bin/sh
# This is a drop-in replacement for cryptsetup's cryptroot script. It
# caches the passphrase in ram, /tmp/unlocks all volumes, then deletes the
# cached passphrase
#
# Standard initramfs preamble
#
#HARDCODED FOR LUCID ON /DEV/SDA5
#
# Standard initramfs preamble
#
prereqs()
{
 # Make sure that cryptall is run last in local-top
 for req in $(dirname $0)/*; do
  script=${req##*/}
  if [ $script != cryptall ]; then
   echo $script
  fi
 done
}

case $1 in
prereqs)
 prereqs
 exit 0
 ;;
esac

plymouth "ask-for-password" --prompt="cryptsetup: unlocking all encrypted boot disks" > /tmp/unlock

cat /tmp/unlock | cryptsetup luksOpen /dev/sda5 cryptroot

 if [ -e /dev/mapper/cryptroot ] ; then

    plymouth message --text="cryptsetup: cryptroot setup successfully"

 else

    plymouth message --text="cryptsetup: unknown fstype, bad password or options?"

    plymouth "ask-for-password" --prompt="cryptsetup: unlocking all encrypted boot disks" > /tmp/unlock

    cat /tmp/unlock | cryptsetup luksOpen /dev/sda5 cryptroot
          if [ -e /dev/mapper/cryptroot ] ; then

               plymouth message --text="cryptsetup: cryptroot setup successfully"

          else

                plymouth message --text="cryptsetup: unknown fstype, bad password or options?"

                plymouth "ask-for-password" --prompt="cryptsetup: unlocking all encrypted boot disks" > /tmp/unlock

                cat /tmp/unlock | cryptsetup luksOpen /dev/sda5 cryptroot

                       if [ -e /dev/mapper/cryptroot ] ; then

                            plymouth message --text="cryptsetup: cryptroot setup successfully"

                        else

                            plymouth message --text="Are you sure you are authorized to boot this computer?"
                            exit 1

                        fi

          fi

 fi

cat /tmp/unlock | cryptsetup luksOpen /dev/sda8 crypthome

    if [ -e /dev/mapper/crypthome ] ; then

         plymouth message --text="cryptsetup: cryptroot setup successfully"

     else

          plymouth message --text="home directory passphrase does not match root key-you need to make a new home key"

    fi

cat /tmp/unlock | cryptsetup luksOpen /dev/sda7 cryptswap

    if [ -e /dev/m...

From time to time I start googling for this feature - and I always end up here. I would appreciate this feature very much. :)

every six months i update, and then i run into this.