Michael wrote, On 02/06/2015 03:19 PM:
If you are concerned about the header, you could use Luks with a detached
header. This way you have the advantages of Luks and you can store the header
separate from the encrypted container.
Beware: there are some warnings in the documentation @
https://code.google.com/p/cryptsetup/wiki/Cryptsetup140
"
WARNING: There is no possible check that specified ciphertext device matches
detached on-disk header.
Use with care, it can destroy your data in case of a mistake.
WARNING: Storing LUKS header in a file means that anti-forensic splitter
cannot properly work
(there is filesystem allocation layer between header and disk)."
cu
Uenal
Quoting dennis@xxxxxxxxxxxxxxxxx:
On Fri, Feb 06, 2015 at 12:51:35AM +0100, Arno Wagner wrote:
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.
...
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.
Count me among the non-experts. I have two questions. (a) Wouldn't
metadata headers incur a loss of plausible deniablity compared to
plain mode, especially when an encrypted filesystem image is stored as
a single file on backup media or in the backing file for a loopback
device? (b) Assuming a secure passphrase, wouldn't plain mode be more
secure than luks against possible vulnerabilities in the hashing
algorithm that may be discovered in the future?
_______________________________________________
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
