From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps344433.stocktonflats.co.uk (vps344433.stocktonflats.co.uk [164.132.228.222]) (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 07:50:37 +0200 (CEST) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by vps344433.stocktonflats.co.uk (Postfix) with ESMTPSA id 462B83E9B4 for ; Mon, 24 Apr 2017 07:50:33 +0200 (CEST) Received: by mail-vk0-f42.google.com with SMTP id q78so33137059vke.3 for ; Sun, 23 Apr 2017 22:50:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <6bbee653-87c7-7145-82fe-785ab6fafece@depressiverobots.com> References: <20170422002548.GA23882@tansi.org> <20170422134557.GB1425@tansi.org> <56144922-1d2e-b97c-3a5b-d7a952c84950@depressiverobots.com> <6bbee653-87c7-7145-82fe-785ab6fafece@depressiverobots.com> From: Dominic Raferd Date: Mon, 24 Apr 2017 06:50:01 +0100 Message-ID: Content-Type: multipart/alternative; boundary=001a114572746e7367054de32f66 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 --001a114572746e7367054de32f66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 April 2017 at 21:03, protagonist wrote: > On 22.04.2017 20:02, protagonist wrote: > > > I've manually compiled > =E2=80=8B...=E2=80=8B > =E2=80=8BThis is pretty impressive stuff to someone like me who is new to d= m-crypt. But I wondered if the chances of the passphrase being misrecorded or misread have been fully considered. In your OP you wrote: 'The password is fairly simple and contains no special characters or locale-sensitive characters and had been written down... none of the characters change between a US layout and the DE layout that was used. There are also no characters that can be easily confused such as O/0.' I note the 'written down' but if by this you meant 'recorded in a Word document', say, then perhaps a capitalisation error has crept in. By far the most likely is that the first character is recorded as capitalised when it isn't (as Word likes to capitalise the letter at the beginning of a sentence).=E2=80=8B Other possibilities include an extra space or spaces (a= t the beginning or end?), or a period being read as part or not part of the passphrase. It would also be worth re-reviewing the possibility that some characters have been confused - if the passphrase was written down by hand the chances greatly increase. And to be quite sure it isn't a keyboard issue, can you try with a DE keyboard? As it happens a single capitalisation error would be picked up by a brute force method that tests for a single bit flip... --001a114572746e7367054de32f66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 23 April 2017 at 21:03, protagonist <listdump@depressiverobots= .com> wrote:
On 22.0= 4.2017 20:02, protagonist wrote:

> I've manually compiled
=E2=80=8B...=E2=80=8B

=
=E2=80=8BThis = is pretty impressive stuff to someone like me who is new to dm-crypt. But I= wondered if the chances of the passphrase being misrecorded or misread hav= e been fully considered. In your OP you wrote: 'The password is fairly = simple and contains no special characters or locale-sensitive characters an= d had been written down... none of the characters change between a US layou= t and the DE layout that was used. There are also no characters that can be= easily confused such as O/0.'

I note the 'written down' but if by this you meant '= recorded in a Word document', say, then perhaps a capitalisation error = has crept in. By far the most likely is that the first character is recorde= d as capitalised when it isn't (as Word likes to capitalise the letter = at the beginning of a sentence).=E2=80=8B Other possibilities include an ex= tra space or spaces (at the beginning or end?), or a period being read as p= art or not part of the passphrase. It would also be worth re-reviewing the = possibility that some characters have been confused - if the passphrase was= written down by hand the chances greatly increase. And to be quite sure it= isn't a keyboard issue, can you try with a DE keyboard?

As it happens a single capitalisation e= rror would be picked up by a brute force method that tests for a single bit= flip...
--001a114572746e7367054de32f66--