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 ; Mon, 24 Apr 2017 15:27:45 +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> From: protagonist Message-ID: <569e04ca-10ae-28fc-9db2-5bf0cb9daea5@depressiverobots.com> Date: Mon, 24 Apr 2017 15:26:20 +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 07:50, Dominic Raferd wrote: > On 22.04.2017 20 :02, protagonist wrote: > > > I've manually compiled > ​...​ > > > ​This is pretty impressive stuff to someone like me who is new to > dm-crypt. Thanks. > But I wondered if the chances of the passphrase being > misrecorded or misread have been fully considered. You make a good point, but 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. > As it happens a single capitalisation error would be picked up by a > brute force method that tests for a single bit flip... This is not the case for any of the bit error tests discussed earlier, as they concern the necessary "decryption ingredients" on disk where bit errors may have occurred, which of course don't include the password itself. Regards, protagonist