Re: LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 24 April 2017 at 14:26, protagonist <listdump@xxxxxxxxxxxxxxxxxxxx> 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)?
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux