[dm-crypt] HELP, luksFormat over existing container

[dm-crypt] HELP, luksFormat over existing container

[Konstantin V. Gavrilenko]

Hello list,

I have a problem :(

by mistake, instead of luksOpen I executed lukFormat on the loop device with associated cryptofile. 
even though the key is was the same, I have no backup of original luksHeader, so I assume i have no way of recovering the SALT.
I am pretty much in Acceptance that it is not possible to recover anything, but would like to get an external confirmation, advice.


p.s. surprised and disappointing that cryptsetup does not issue a warning when running luksFormat over luks preformatted container :(

thanks
kos

Re: [dm-crypt] HELP, luksFormat over existing container

[Arno Wagner]

On Sat, Jan 07, 2012 at 10:57:08AM -0000, Konstantin V. Gavrilenko wrote:
> Hello list,
> 
> I have a problem :(
> 
> by mistake, instead of luksOpen I executed lukFormat on the loop device
> with associated cryptofile.  even though the key is was the same, I have
> no backup of original luksHeader, so I assume i have no way of recovering
> the SALT.  

And the master key is different in addition, at least in the first
key-slot that also has been overwritten.

> I am pretty much in Acceptance that it is not possible to
> recover anything, but would like to get an external confirmation, advice.

You are correct. Next step is to fix your set-up by adding
backup, see the FAQ.  
 
> p.s. surprised and disappointing that cryptsetup does not issue a warning
> when running luksFormat over luks preformatted container :(

It gives you a very clear warning and asks for an uppercase "YES"
and asks for the passphrease two times. That _should_ be enough. 
There is only so much a tool can do to protect you. The UNIX way is
to warn you, but to assume you want to do what you specified if
you ignore the warning. 

There are a number of ways to kill the header that give a lot less 
warning. Or none at all. Also the FAQ warns very, very clearly that 
you _need_ a backup and should have a header backup. The backup
is the second line of defense and one of its major tasks is to
protect against user errors.

See it this way: Most people do not bother with backup until
they lose something important. The earlier you make that 
experience, the better.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] HELP, luksFormat over existing container

[Konstantin V. Gavrilenko]

----- Original Message -----
From: "Arno Wagner" <arno@wagner.name>
To: dm-crypt@saout.de
Sent: Saturday, 7 January, 2012 12:48:16 PM
Subject: Re: [dm-crypt] HELP, luksFormat over existing container

On Sat, Jan 07, 2012 at 10:57:08AM -0000, Konstantin V. Gavrilenko wrote:
> Hello list,
> 
> I have a problem :(
> 
> by mistake, instead of luksOpen I executed lukFormat on the loop device
> with associated cryptofile.  even though the key is was the same, I have
> no backup of original luksHeader, so I assume i have no way of recovering
> the SALT.  

And the master key is different in addition, at least in the first
key-slot that also has been overwritten.

KVG: I see, so the cryptsetup generates a different master key at each luksFormat eventhough the original key is the same, no hope for me then  :(((

> I am pretty much in Acceptance that it is not possible to
> recover anything, but would like to get an external confirmation, advice.

You are correct. Next step is to fix your set-up by adding
backup, see the FAQ.  
 
KVG:((( i had some files that were not backed up.

> p.s. surprised and disappointing that cryptsetup does not issue a warning
> when running luksFormat over luks preformatted container :(

It gives you a very clear warning and asks for an uppercase "YES"
and asks for the passphrease two times. That _should_ be enough. 
There is only so much a tool can do to protect you. The UNIX way is
to warn you, but to assume you want to do what you specified if
you ignore the warning. 


KVG: No it did not give the warning. I guess it depends on how the cryptsetup is used.
In my case, I have a gpg protected key, that I pipe to cryptsetup once it is decrypted.
Here is an example, two luksFormats in a row and no warning that luks header exists.


root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
Command successful.
root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
Command successful.






There are a number of ways to kill the header that give a lot less 
warning. Or none at all. Also the FAQ warns very, very clearly that 
you _need_ a backup and should have a header backup. The backup
is the second line of defense and one of its major tasks is to
protect against user errors.

See it this way: Most people do not bother with backup until
they lose something important. The earlier you make that 
experience, the better.


KVG: vielen Dank, noted :)


Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] HELP, luksFormat over existing container

[Arno Wagner]

On Sun, Jan 08, 2012 at 09:59:02AM -0000, Konstantin V. Gavrilenko wrote:
> 
> ----- Original Message -----
> From: "Arno Wagner" <arno@wagner.name>
> To: dm-crypt@saout.de
> Sent: Saturday, 7 January, 2012 12:48:16 PM
> Subject: Re: [dm-crypt] HELP, luksFormat over existing container
> 
> On Sat, Jan 07, 2012 at 10:57:08AM -0000, Konstantin V. Gavrilenko wrote:
> > Hello list,
> > 
> > I have a problem :(
> > 
> > by mistake, instead of luksOpen I executed lukFormat on the loop device
> > with associated cryptofile.  even though the key is was the same, I have
> > no backup of original luksHeader, so I assume i have no way of recovering
> > the SALT.  
> 
> And the master key is different in addition, at least in the first
> key-slot that also has been overwritten.
> 
> KVG: I see, so the cryptsetup generates a different master key at each
> luksFormat eventhough the original key is the same, no hope for me then
> :(((

It has to do this in order to support multiple passphrases.
 
> > I am pretty much in Acceptance that it is not possible to
> > recover anything, but would like to get an external confirmation, advice.
> 
> You are correct. Next step is to fix your set-up by adding
> backup, see the FAQ.  
>  
> KVG:((( i had some files that were not backed up.
> 
> > p.s. surprised and disappointing that cryptsetup does not issue a warning
> > when running luksFormat over luks preformatted container :(
> 
> It gives you a very clear warning and asks for an uppercase "YES"
> and asks for the passphrease two times. That _should_ be enough. 
> There is only so much a tool can do to protect you. The UNIX way is
> to warn you, but to assume you want to do what you specified if
> you ignore the warning. 
> 

> 
> KVG: No it did not give the warning. I guess it depends on how the
> cryptsetup is used.  In my case, I have a gpg protected key, that I pipe
> to cryptsetup once it is decrypted.  Here is an example, two luksFormats
> in a row and no warning that luks header exists.
>  
> root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> gpg: CAST5 encrypted data
> gpg: gpg-agent is not available in this session
> gpg: encrypted with 1 passphrase
> gpg: WARNING: message was not integrity protected
> Command successful.
> root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> gpg: CAST5 encrypted data
> gpg: gpg-agent is not available in this session
> gpg: encrypted with 1 passphrase
> gpg: WARNING: message was not integrity protected
> Command successful.

Well, if you script this, then the responsibility for 
the warning goes over to you. This does make sense,
because when cryptsetup is fed from STDIN, it has
no clue what its STDOUT and STDERR are attached to.
For all it knows, it may be used from a GUI. It only
goes "interactive" when its STDIN is attached to a 
terminal.

I am wondering how you were hit by that though. Do
you input this command-chain manually? 

> There are a number of ways to kill the header that give a lot less 
> warning. Or none at all. Also the FAQ warns very, very clearly that 
> you _need_ a backup and should have a header backup. The backup
> is the second line of defense and one of its major tasks is to
> protect against user errors.
> 
> See it this way: Most people do not bother with backup until
> they lose something important. The earlier you make that 
> experience, the better.
> 
> KVG: vielen Dank, noted :) 

You are welcome. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] HELP, luksFormat over existing container

[Konstantin V. Gavrilenko]

----- Original Message -----
From: "Arno Wagner" <arno@wagner.name>
To: dm-crypt@saout.de
Sent: Sunday, 8 January, 2012 11:40:05 AM
Subject: Re: [dm-crypt] HELP, luksFormat over existing container

On Sun, Jan 08, 2012 at 09:59:02AM -0000, Konstantin V. Gavrilenko wrote:
> 
> ----- Original Message -----
> From: "Arno Wagner" <arno@wagner.name>
> To: dm-crypt@saout.de
> Sent: Saturday, 7 January, 2012 12:48:16 PM
> Subject: Re: [dm-crypt] HELP, luksFormat over existing container
> 
> On Sat, Jan 07, 2012 at 10:57:08AM -0000, Konstantin V. Gavrilenko wrote:
> > Hello list,
> > 
> > I have a problem :(
> > 
> > by mistake, instead of luksOpen I executed lukFormat on the loop device
> > with associated cryptofile.  even though the key is was the same, I have
> > no backup of original luksHeader, so I assume i have no way of recovering
> > the SALT.  
> 
> And the master key is different in addition, at least in the first
> key-slot that also has been overwritten.
> 
> KVG: I see, so the cryptsetup generates a different master key at each
> luksFormat eventhough the original key is the same, no hope for me then
> :(((

It has to do this in order to support multiple passphrases.

KVG: I relied on pgp for this, since the times when I used to use loop-aes.
besides, IMHPO there is an added benefit of having the key that is opened by the passphrase, so if shit hits the fan, you just shred the key, and knowing the passphrase would not unlock the crypto partition.



> > I am pretty much in Acceptance that it is not possible to
> > recover anything, but would like to get an external confirmation, advice.
> 
> You are correct. Next step is to fix your set-up by adding
> backup, see the FAQ.  
>  
> KVG:((( i had some files that were not backed up.
> 
> > p.s. surprised and disappointing that cryptsetup does not issue a warning
> > when running luksFormat over luks preformatted container :(
> 
> It gives you a very clear warning and asks for an uppercase "YES"
> and asks for the passphrease two times. That _should_ be enough. 
> There is only so much a tool can do to protect you. The UNIX way is
> to warn you, but to assume you want to do what you specified if
> you ignore the warning. 
> 

> 
> KVG: No it did not give the warning. I guess it depends on how the
> cryptsetup is used.  In my case, I have a gpg protected key, that I pipe
> to cryptsetup once it is decrypted.  Here is an example, two luksFormats
> in a row and no warning that luks header exists.
>  
> root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> gpg: CAST5 encrypted data
> gpg: gpg-agent is not available in this session
> gpg: encrypted with 1 passphrase
> gpg: WARNING: message was not integrity protected
> Command successful.
> root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> gpg: CAST5 encrypted data
> gpg: gpg-agent is not available in this session
> gpg: encrypted with 1 passphrase
> gpg: WARNING: message was not integrity protected
> Command successful.

Well, if you script this, then the responsibility for 
the warning goes over to you. This does make sense,
because when cryptsetup is fed from STDIN, it has
no clue what its STDOUT and STDERR are attached to.
For all it knows, it may be used from a GUI. It only
goes "interactive" when its STDIN is attached to a 
terminal.

KVG: wouldn't it be better to have a full proof solution, so if you want the cryptseup to stop being interactive and use it in a script, then there could be additional switch like --noninteractive, in all other cases it would issue a warning. 


I am wondering how you were hit by that though. Do
you input this command-chain manually? 


KVG: yes, i did. just copied and pasted the wrong line from a file  :( late at night, after a very very long day at work  :( since i didn't get any warning i didn't suspect anything until too late. well, it didnt take long, just one command and correctly entered gpg passphrase.



for password holding cryptopartion, i've  scripted it

#!/bin/bash
DEVICEPATH="/root/cryptofile.dat"
MNTDIR="/root/Crypto"
KEYPATH="/root/keyfile.gpg"

check_root ()
 {
        ### Check if root
        if [ `id -un` != "root" ]; then
                echo -e "\n!!!Not executed as root, re-executing myself with sudo...."
                exec sudo sh $0 $*
        fi
 }

check_key_exists ()
 {
        ###Check if gpg key exists and readable
        test -r $KEYPATH ||  { echo -e "\n!!! $KEYPATH keyfile not found";  exit; }
 }

check_dir_exists ()
 {
        ###Check if $MNTDIR correspond to a real dir
        test -d $MNTDIR ||  { echo -e "\n!!! $MNTDIR is not there";  exit; }
 }

determine_loop ()
 {
        ###check if container is already mounted on loopX device
        ESCAPED_DEVICEPATH=`echo $DEVICEPATH | sed 's,/,\\\/,g'`
        LOOPDEV=`losetup -a | awk '/'${ESCAPED_DEVICEPATH}'/ {print $1}'`
        LOOPDEV=${LOOPDEV%:}
 }

determine_cryptodevice ()
 {
        ###Find out whether or not $DEVICEPATH has already been set up in dm-crypt.
        CRYPTOMAP=`echo $DEVICEPATH | sed 's,/,_,g'`
 }




case $1 in

mount)
        check_root

        check_key_exists
        check_dir_exists

        determine_loop
        if [ $LOOPDEV ]; then
                # We already have one; need to trim final ':' from output of `losetup -a`.
                echo -e "\n * $DEVICEPATH is already set up as $LOOPDEV"
         else
                LOOPDEV=`losetup -f`
                test -n "$LOOPDEV" || { echo -e "\n!!! No free loopdevices"; exit 1; }
                echo -e "\n * $LOOPDEV selected for loopdevice"
                losetup $LOOPDEV $DEVICEPATH || { echo -e "\n!!! unable to associate the $LOOPDEV with $DEVICEPATH"; exit 1; }
                echo "   Done"
        fi

        determine_cryptodevice
        if [ -z `ls /dev/mapper | awk '/'${CRYPTOMAP}'/'` ]; then
            echo -e "\n * Setting up $LOOPDEV as encrypted container $CRYPTOMAP"
                gpg --decrypt $KEYPATH 2>/dev/null | cryptsetup luksOpen $LOOPDEV $CRYPTOMAP || { echo -e "!!! Unable to initialise $CRYPTOMAP"; exit 1; }
            echo "   Done"
        else
            echo -e "\n * $LOOPDEV is already set up as encrypted container $CRYPTOMAP"
        fi



        ###Find out whether or not $CRYPTOMAP has already been mounted on $MNTDIR.
        if [ -z `df | awk '/\/dev\/mapper\/'${CRYPTOMAP}'/'` ]; then
            echo  -e "\n * Mounting /dev/mapper/$CRYPTOMAP on $MNTDIR"
            mount "/dev/mapper/$CRYPTOMAP" "$MNTDIR" || { echo -e "!!! Unable to mount $CRYPTOMAP on $MNTDIR"; exit 1; }
            echo "   Done"
        else
            echo -e "\n * $CRYPTOMAP is already mounted on $MNTDIR"
        fi
;;


umount)
        check_root

        determine_cryptodevice
        ###Find out whether or not $CRYPTOMAP is still mounted on $MNTDIR.
        if [ `df | awk '/\/dev\/mapper\/'${CRYPTOMAP}'/'` ]; then
            echo -e "\n * Unmounting /dev/mapper/$CRYPTOMAP"
            umount /dev/mapper/$CRYPTOMAP || { echo -e "!!! Unable to umount $CRYPTOMAP"; exit 1; } 
            echo "   Done"
         else
            echo -e "\n * /dev/mapper/$CRYPTOMAP not mounted"
        fi

        ###Find out whether or not $DEVICEPATH is still set up in dm-crypt.
        if [ `ls /dev/mapper | awk '/'${CRYPTOMAP}'/'` ]; then
           echo  -e "\n * Tearing down encrypted container /dev/mapper/$CRYPTOMAP"
           cryptsetup luksClose $CRYPTOMAP || { echo -e "!!! Unable to close $CRYPTOMAP"; exit 1; }
           echo "   Done"
        else
           echo -e "\n * /dev/mapper/$CRYPTOMAP doesnt exist"
        fi

        determine_loop
        if [ $LOOPDEV ]; then
           echo -e "\n * Tearing down $LOOPDEV"
           losetup -d $LOOPDEV || { echo -e "!!! Unable to remove associations from $LOOPDEV"; exit 1; }
           echo "   Done"
        else
           echo -e "\n * $DEVICEPATH isnt bound to any loopback device"
        fi
;;

*)
        echo -e "\n\nExecute: ./cryptostart.sh ( mount | unmount )"
        echo -e "\n  Set the details of your crypto devices within the script"
        exit
        ;;
esac








> There are a number of ways to kill the header that give a lot less 
> warning. Or none at all. Also the FAQ warns very, very clearly that 
> you _need_ a backup and should have a header backup. The backup
> is the second line of defense and one of its major tasks is to
> protect against user errors.
> 
> See it this way: Most people do not bother with backup until
> they lose something important. The earlier you make that 
> experience, the better.
> 
> KVG: vielen Dank, noted :) 

You are welcome. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] HELP, luksFormat over existing container

[Arno Wagner]

On Sun, Jan 08, 2012 at 01:23:27PM -0000, Konstantin V. Gavrilenko wrote:
> ----- Original Message -----
> From: "Arno Wagner" <arno@wagner.name>
> To: dm-crypt@saout.de
> Sent: Sunday, 8 January, 2012 11:40:05 AM
> Subject: Re: [dm-crypt] HELP, luksFormat over existing container
> 
> On Sun, Jan 08, 2012 at 09:59:02AM -0000, Konstantin V. Gavrilenko wrote:
> > 
> > ----- Original Message -----
> > From: "Arno Wagner" <arno@wagner.name>
> > To: dm-crypt@saout.de
> > Sent: Saturday, 7 January, 2012 12:48:16 PM
> > Subject: Re: [dm-crypt] HELP, luksFormat over existing container
> > 
> > On Sat, Jan 07, 2012 at 10:57:08AM -0000, Konstantin V. Gavrilenko wrote:
> > > Hello list,
> > > 
> > > I have a problem :(
> > > 
> > > by mistake, instead of luksOpen I executed lukFormat on the loop device
> > > with associated cryptofile.  even though the key is was the same, I have
> > > no backup of original luksHeader, so I assume i have no way of recovering
> > > the SALT.  
> > 
> > And the master key is different in addition, at least in the first
> > key-slot that also has been overwritten.
> > 
> > KVG: I see, so the cryptsetup generates a different master key at each
> > luksFormat eventhough the original key is the same, no hope for me then
> > :(((
> 
> It has to do this in order to support multiple passphrases.

> 
> KVG: I relied on pgp for this, since the times when I used to use
> loop-aes.  besides, IMHPO there is an added benefit of having the key that
> is opened by the passphrase, so if shit hits the fan, you just shred the
> key, and knowing the passphrase would not unlock the crypto partition.


That would be the right approach for plain dm-crypt. For LUKS this
is not needed anymore, see FAQ item(s) on deleting a LUKS partition.


> > > I am pretty much in Acceptance that it is not possible to
> > > recover anything, but would like to get an external confirmation, advice.
> > 
> > You are correct. Next step is to fix your set-up by adding
> > backup, see the FAQ.  
> >  
> > KVG:((( i had some files that were not backed up.
> > 
> > > p.s. surprised and disappointing that cryptsetup does not issue a warning
> > > when running luksFormat over luks preformatted container :(
> > 
> > It gives you a very clear warning and asks for an uppercase "YES"
> > and asks for the passphrease two times. That _should_ be enough. 
> > There is only so much a tool can do to protect you. The UNIX way is
> > to warn you, but to assume you want to do what you specified if
> > you ignore the warning. 
> > 
> 
> > 
> > KVG: No it did not give the warning. I guess it depends on how the
> > cryptsetup is used.  In my case, I have a gpg protected key, that I pipe
> > to cryptsetup once it is decrypted.  Here is an example, two luksFormats
> > in a row and no warning that luks header exists.
> >  
> > root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> > gpg: CAST5 encrypted data
> > gpg: gpg-agent is not available in this session
> > gpg: encrypted with 1 passphrase
> > gpg: WARNING: message was not integrity protected
> > Command successful.
> > root@dmob:/# gpg --decrypt /tmp/keyfile.gpg | cryptsetup -v --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/loop0
> > gpg: CAST5 encrypted data
> > gpg: gpg-agent is not available in this session
> > gpg: encrypted with 1 passphrase
> > gpg: WARNING: message was not integrity protected
> > Command successful.
> 
> Well, if you script this, then the responsibility for 
> the warning goes over to you. This does make sense,
> because when cryptsetup is fed from STDIN, it has
> no clue what its STDOUT and STDERR are attached to.
> For all it knows, it may be used from a GUI. It only
> goes "interactive" when its STDIN is attached to a 
> terminal.

> 
> KVG: wouldn't it be better to have a full proof solution, so if you want
> the cryptseup to stop being interactive and use it in a script, then there
> could be additional switch like --noninteractive, in all other cases it
> would issue a warning.

Not really. There is a point where you have to asume the 
user knows what he is doing. Your usage is pretty bizarre for
LUKS, but completely typical for use from a script. The
next issue is that even if cryptsetup prints the warning, there 
is absolutely no way for it to ensure that warning is seen. 
Just think of this being a GTK+ (for example) graphical wrapper.
 
So, sorry, but reading the documentation and being careful is
mandatory for safe and secure crypto usage. There is just no way
around that. It is too difficult to get right without some 
understanding of the subject matter. At the same time, there is
a strong dependency on the application scenario.

> I am wondering how you were hit by that though. Do
> you input this command-chain manually? 
> 
> 
> KVG: yes, i did. just copied and pasted the wrong line from a file  :(
> late at night, after a very very long day at work :( since i didn't get
> any warning i didn't suspect anything until too late.  well, it didnt take
> long, just one command and correctly entered gpg passphrase.

Well, there is a second lesson here. The situation is typical
BTW, that is why I by now refrain from doing anything potentially
dangerous when tired. Added safety measures would include to 
not have the normal and the dangerous line in a file and 
scripting this instead of copying it. 

And if you think about it, you could have just had the line
with '--noninteractive' in there as well, as you would have
needed to use it actually for the line to work. So again, 
nothing that cryptsetyp can do. It really is the wrong place 
to fix this. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell