From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 8 Feb 2015 11:09:56 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKOoM-0000R5-Gl for dm-crypt@saout.de; Sun, 08 Feb 2015 11:09:54 +0100 Received: from ip4d151e07.dynamic.kabel-deutschland.de ([77.21.30.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 11:09:54 +0100 Received: from for-gmane by ip4d151e07.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 11:09:54 +0100 From: "U.Mutlu" Date: Sun, 08 Feb 2015 11:09:48 +0100 Message-ID: References: <20150205115435.GA4093@tansi.org> <20150205235135.GA21304@tansi.org> <20150206140140.GA16920@dashborg.com> <20150206182729.GB7283@tansi.org> <20150207172747.GA26528@dashborg.com> <20150207180356.GA4982@fritha.org> <20150207231624.GA23872@citd.de> <20150208081954.GA2856@fritha.org> <20150208092334.GA20982@tansi.org> <54D73297.7060904@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <54D73297.7060904@gmail.com> Subject: Re: [dm-crypt] plain: opening with a wrong password List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Milan Broz wrote, On 02/08/2015 10:55 AM: > On 02/08/2015 10:23 AM, Arno Wagner wrote: >> On Sun, Feb 08, 2015 at 09:19:54 CET, Heinz Diehl wrote: > >> Form a purely practical perspective, the difference usually negligible. >> Wile plain dm-crypt mounting fails at the mount-stage due to wrong >> filesystem signatures, LUKS mounting fails at the decrypt stage. > > Beware, there are some combinations of the encryption mode + IV which decrypts > the first block correctly in both cases, so fs returns correct signature > but fs is obviously corrupted... if you are not lucky, fsck will run > and breaks the fs irrecoverably... > > This cannot happen with LUKS. > > See here that the ext3 device created with ESSIV still have visible signature > with plain IV: > > # echo "password" | cryptsetup create -c aes-cbc-essiv:sha256 -s 256 x /dev/sdb > # mkfs -t ext3 -q /dev/mapper/x > # blkid -p /dev/mapper/x > /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" > > ... use fs > # cryptsetup close x > > And now thy mistake with plain IV: > > # echo "password" | cryptsetup create -c aes-cbc-plain -s 256 x /dev/sdb > # blkid -p /dev/mapper/x > /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" > > # mount /dev/mapper/x /mnt/tst > mount: wrong fs type, bad option, bad superblock on /dev/mapper/x, > missing codepage or helper program, or other error > ... > > DO NOT use plain mode if you are not sure what you are doing. Really. > > There is a detached LUKS header which is better, the issues I mentioned in man > about detached header page are side problems, nothing serious for most users. > (But obviously depends on your threat model.) > > Milan But isn't it just saying that the mount cannot be done because something is wrong, ie. wrong/incomplete cipher param was given? What happens if you repeat the whole with the correct params? And, should one not use "/dev/sdb1" etc. instead of "/dev/sdb"? -- cu Uenal