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 écrit : > >>>>>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/device. > >> > >>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 hasher 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
