From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (195-159-176-226.customer.powertech.no [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Mon, 29 Jul 2019 16:11:33 +0200 (CEST) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hs68a-000i9x-9H for dm-crypt@saout.de; Mon, 29 Jul 2019 15:56:28 +0200 From: Robert Nichols Date: Mon, 29 Jul 2019 08:56:21 -0500 Message-ID: References: <1313728220.30.1564401565268.JavaMail.gkos@xpska> <1853881426.34.1564402130365.JavaMail.gkos@xpska> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <1853881426.34.1564402130365.JavaMail.gkos@xpska> Content-Language: en-US Subject: Re: [dm-crypt] LUKS Header crruption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de The key material is quite deliberately made just the opposite of redundant. It is artificially inflated (typically 4000X) to occupy a larger area of the disk, and in such a manner that successfully erasing any portion of that area makes the key unrecoverable. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. On 7/29/19 7:08 AM, Konstantin V. Gavrilenko wrote: > Thanks Arno, thought so :( > Its a real pity that metadata is not redundant in luks v1. > > Regards, > Konstantin > > > > ----- Original Message ----- > From: "Arno Wagner" > To: dm-crypt@saout.de > Sent: Sunday, 28 July, 2019 11:00:49 PM > Subject: Re: [dm-crypt] LUKS Header crruption > > Hi Konstantin, > > sorry, you data is gone. You overwrote the start of the first > key-slot and there is no way to recover from that without backup. > > One of the reasons why I think RAID superblocks at the start of the > device (and even more so at 4kB offset) are messed up and a sign > of clueless designers. > > Regards, > Arno