Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors

[Dominic Raferd <dominic@timedicer.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On 24 April 2017 at 14:26, protagonist <listdump@depressiverobots.com>
wrote:

>
>
> 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"
> value.
> 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,
passphrase)?

[-- Attachment #2: Type: text/html, Size: 2603 bytes --]