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 é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
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
