[dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors
dominic at timedicer.co.uk
Mon Apr 24 19:00:27 CEST 2017
On 24 April 2017 at 14:26, protagonist <listdump at depressiverobots.com>
> On 24.04.2017 07:50, Dominic Raferd wrote:
> > On 22.04.2017 20 <tel:22.04.2017%2020>:02, protagonist wrote:
> > > I've manually compiled
> > ...
> as the password has been written down on
> paper the old-fashioned way, I have decided to take it as a "known good"
> One can speculate about the password being wrong on paper, or some
> laptop-specific oddity, but as the owner had been entering it daily for
> more than a year, I don't think a simple single-character swap for
> neighboring keys or capitalization changes will help. In other
> situations, they might, and bruteforce complexity only grows linearly
> with the number of changes and password length, respectively, if one
> looks for a single error, so it's definitely something to consider for
> passwords that can't be remembered perfectly.
You seem to have considered the options pretty thoroughly. If the original
owner has come to you, so s/he knows they have been typing in the same
passphrase until one day it stopped working - and they have told you that
passphrase, then an error in recording the passphrase can be discounted. If
the situation is otherwise then a wrong passphrase still seems to me more
likely than a corrupted LUKS header, especially when everything you can
test on the disk seems ok.
Is there any possibility that a malicious third party (disgruntled
ex-sysadmin perhaps) gained root access to the machine during its last
session and changed the passphrase? As an aside, of no help to OP I'm
afraid: is a prior backup of the LUKS header a protection against this
scenario (i.e. against a subsequently deleted, or changed and now unknown,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt