From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.depressiverobots.com (depressiverobots.com [85.14.254.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 25 Apr 2017 01:51:11 +0200 (CEST) References: <20170422002548.GA23882@tansi.org> <20170422134557.GB1425@tansi.org> <56144922-1d2e-b97c-3a5b-d7a952c84950@depressiverobots.com> <6bbee653-87c7-7145-82fe-785ab6fafece@depressiverobots.com> <569e04ca-10ae-28fc-9db2-5bf0cb9daea5@depressiverobots.com> From: protagonist Message-ID: Date: Tue, 25 Apr 2017 01:49:46 +0200 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 24.04.2017 19:00, Dominic Raferd wrote: > 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. This is the case. The disk had been used in a privately owned laptop. > 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)? If a malicious program had been able to run as root and deliberately wrote into the LUKS header sectors to corrupt them, it definitely did so in a very "plausible" fashion in terms of writing pseudo-random values in the allowed areas. Given the fact that this was a fairly low-value target, I doubt there was any reason to do this in such a "stealthy" fashion if making the disk unusable had been the intention of such a hypothetical malware. It's basically impossible to find out at this point whether or not that was the case, but it's a scary thought that should make everyone do header backups. Regarding a "change" of passphrases: A program would need access to the master key of the disk to create a new, working key slot. As far as I know, a valid passphrase would be needed during the normal cryptsetup procedures to open one of the existing key slots, extract the master key and build the new keyslot data containing a new copy of the master key. However, I assume it is likely that a determined attacker running as root might be able to extract the master key from RAM if the encrypted volume in question is still open at the time of attack, so technically, there would be a way to do this without the password. I've asked the owner about mnemonics for the password, and they indeed checked out, so I'd consider the passphrase integrity question as settled in this case. Regards, protagonist