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 ; Fri, 6 Feb 2015 15:04:36 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YJjWJ-0006mO-Ff for dm-crypt@saout.de; Fri, 06 Feb 2015 15:04:31 +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 ; Fri, 06 Feb 2015 15:04:31 +0100 Received: from for-gmane by ip4d151e07.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Feb 2015 15:04:31 +0100 From: "U.Mutlu" Date: Fri, 06 Feb 2015 15:04:25 +0100 Message-ID: References: <54D21872.2030406@yahoo.com> <20150205115435.GA4093@tansi.org> <20150205235135.GA21304@tansi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable In-Reply-To: <20150205235135.GA21304@tansi.org> 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 Arno Wagner wrote, On 02/06/2015 12:51 AM: > On Thu, Feb 05, 2015 at 15:04:39 CET, U.Mutlu wrote: >> U.Mutlu wrote, On 02/05/2015 02:53 PM: >>> Arno Wagner wrote, On 02/05/2015 12:54 PM: >>>> On Wed, Feb 04, 2015 at 14:30:17 CET, U.Mutlu wrote: >>>>> Quentin Lefebvre wrote, On 02/04/2015 02:02 PM: >>>>>> Hi, >>>>>> >>>>>> Le 04/02/2015 13:33, U.Mutlu a =E9crit : >>>>>>> Hi, >>>>>>> what happens if an encrypted filesystem (plain, no LUKS) >>>>>>> next time is opened accidently with a wrong password, >>>>>>> and new data written to it? Will the filesystem then become >>>>>>> damaged/unusable? >>>>>> >>>>>> What typically happens when you use a wrong password is that the >>>>>> cryptsetup create/open command is indeed successful, but mounting = your >>>>>> partition will fail (because the filesystem is not detected). So = you >>>>>> have few chance to accidentally damage a filesystem, even in plain= >>>>>> mode. >>>>> >>>>> I tried this out now, and indeed that's cool! >>>>> Thank you for this useful tip, it spares me to study further >>>>> also the LUKS stuff, as plain is IMHO sufficient for my needs. >>>>> The main drawback with plain seems to be that one cannot change >>>>> the password, instead one needs to re-enrcrypt into a new file/devi= ce. >>>> >>>> That, you have only one password, and you do not get some >>>> additional protection for weak passwords from salting and >>>> iteration. With a good, passphease plain is about as secure >>>> as LUKS, namely not breakable. (See FAQ item 5.1 for details >>>> of what "good" means.) >>>> >>>> Arno >>> >>> Yes, and one better should create a password by using a password hash= er like >>> the following: >>> $ echo mypassword | hashalot -x -s mysalt sha256 >>> 5d9de7f56a469782ff8a6be363418f62d6f93e33c3adb5c216e7e9c2f9947240 >>> and pass the result to the target (of course using something else for= >>> "mypassword" and "mysalt"). >> >> Oh, I forgot to mention: with such a strong password >> "plain" is IMHO more secure than "luks" b/c plain offers >> no attack vectors (ie. metadata headers). > > Actually, it is not. I do disagree on the hashalot approach > as well. If your passphrase is weak enough that a dictionary > attack has a reasonable success of working (and a dictionary > attack is the only thing the salt that hashalot adds helps > against), then you are pretty deep in insecure territory and > _need_ the hash iteration that LUKS provides, but which is > missing from both plain and hashalot. > > Aso, you can simulate a salt directly with plain as follows: > Just give your passphrase and append the known salt. That is > about as secure as the more complicated approach with hashalot. > > The other thing is that the LUKS metadata-headers do not make > attacks any easier. They do _not_ provide "attack vectors". > Salts are per definition not secret. If you make the salt > secret, you are doing it wrong. Instead append the secret to > the passphrase and add a non-secret salt. The only other thing > an attacker gets is the iteration count. That one does not > add a lot of protection if unknown (after all, the iteration > time is known and likely also the CPU it was done on), but > its needed for deriving the key in legitimate unlocks. > > Please do not spread unsubstantiated rumors. It is hard enough > these days for non-experts to decide what crypto to trust > and what not. Rumors of the kind "metadata headers offer > attack vectors" make this even worse. > > Arno IMO that's a question of logic: A security system which stores the password in its header (ie. LUKS) cannot be secure against another system ("plain") that does nowhere store the password. In the case of LUKS the attacker knows more about the system than in the case of "plain". Ergo "plain" is more secure than LUKS. LUKS uses a static master key (as does plain). The slot passwords are for authenticating the access to the filesystem by the management tool (cryptsetup) only. Ie. the slot passwords have nothing to do with the encryption. cu Uenal