[dm-crypt] plain: opening with a wrong password
for-gmane at mutluit.com
Fri Feb 6 15:47:41 CET 2015
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 @
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)."
> Quoting dennis at basis.uklinux.net:
>> 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?
More information about the dm-crypt