On 24 April 2017 at 14:26, protagonist wrote: > > > On 24.04.2017 07:50, Dominic Raferd wrote: > > On 22.04.2017 20 :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)?