On Sun, Jan 08, 2012 at 09:59:02AM -0000, Konstantin V. Gavrilenko wrote: > > ----- Original Message ----- > From: "Arno Wagner" <arno@xxxxxxxxxxx> > To: dm-crypt@xxxxxxxx > Sent: Saturday, 7 January, 2012 12:48:16 PM > Subject: Re: 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@xxxxxxxxxxx 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@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
