From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glkdd-dm-crypt@m.gmane.org>
Received: from blaine.gmane.org (unknown [195.159.176.226])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sat, 22 Apr 2017 15:33:38 +0200 (CEST)
Received: from list by blaine.gmane.org with local (Exim 4.84_2)
 (envelope-from <glkdd-dm-crypt@m.gmane.org>) id 1d1vAG-0004L8-Td
 for dm-crypt@saout.de; Sat, 22 Apr 2017 15:33:28 +0200
From: Robert Nichols <rnicholsNOSPAM@comcast.net>
Date: Sat, 22 Apr 2017 08:33:28 -0500
Message-ID: <odfm32$fpm$1@blaine.gmane.org>
References: <a6e54426-5188-d4c7-ee7b-6f022b84bf22@depressiverobots.com>
 <f11f16b9-bbcd-4484-bc4b-403d25dc00b5@depressiverobots.com>
 <20170422002548.GA23882@tansi.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
In-Reply-To: <20170422002548.GA23882@tansi.org>
Subject: Re: [dm-crypt] LUKS header recovery attempt from apparently healthy
 SSD
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 04/21/2017 07:25 PM, Arno Wagner wrote:
> Aassume 1 bit has been corrupted in a random place.
> A key-slot is 256kB, i.e. 2Mbit. That means trying it
> out (flip one bit, do an unlock attempt) would take
> 2 million seconds on the original PC, i.e. 23 days.
> This can maybe be brought down by a factor of 5 or so
> with the fastest avaliable CPU (the oteration count of
> 150k is pretty low), i.e. still roughly 5 days.
>
> This may be worth giving it a try, but it requires some
> serious coding with libcryptsetup and it will only
> help on a single bit-error.
>
> It may of course be a more complex error, especially
> when ECC in the disk has corrected an error to the
> wrong value, because the original was too corrupted.

The drive would almost certainly have detected and corrected a single-bit error.

>
> The keyslot checker is no help here, it is intendend
> to find gross localized corruption,

It is still worth running the keyslot checker to detect gross corruption before spending 5+ days in a (probably futile) search for a single bit flip.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.