Re: Corrupted luks partition, help needed

[Panagiotis Malakoudis <malakudi@xxxxxxxxx>]

A single bit flip can happen, especially in USB keys (I had the corruption in such a key). It can also happen to disks, by faulty hardware controllers, overclocked buses etc. The point here is that a single bit flip invalidates all your data. A sector corruption in the partition table does indeed invalidate your data, but it is really easy to reconstruct it. A corruption in the raid superblock also invalidates your data, but this can also be reconstructed (not really easy, but it can be done). But a corruption in the LUKS header cannot be undone. Of course, everyone should backup critical data, residing in encrypted disks or not, however, loosing all your data just because you lost one sector of the storage device is something that should be somehow not allowed to happen.

I can suggest two things. A second copy of the first part of the LUKS header (not the keyslots), residing just after the keyslots. And parity information to keyslot data, in order to avoid the corruption that you loose some bytes or one sector.

cryptsetup should also state very clearly the risks of not backing up the LUKS header. I consider myself a very good linux sysadmin but I wasn't really aware of the single point of failure that the LUKS header is. Now I am aware.

On Fri, Jun 4, 2010 at 1:07 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote:

On Thu, Jun 03, 2010 at 10:48:18PM +0200, Luca Berra wrote:
> On Thu, Jun 03, 2010 at 10:14:53PM +0200, Arno Wagner wrote:
>> On Thu, Jun 03, 2010 at 09:05:59PM +0300, Panagiotis Malakoudis wrote:
>>> OK, I looked a bit more inside LUKS specification and I now know that the
>>> 128KB keyslot is actually the 32byte master key AF-split to 128KB and then
>>> encoded with my key. A single bit of change in these 128KB makes key
>>> invalid.
>>>
>>> Now that I know all this, I consider the LUKS format fundamentally flawed to
>>> data corruption.
>>
>> It is. However this area should not be written by anything except
>> cryoptsetup. If you look closely basically every filesystem
>> and partition scheme is about as vulnerable. The thing is,
>> modern disks do not suffer single bit corruption easily. More
>> likely are whole lost sectors.
>
> well, actually if you look closely at modern filesystems and
> partitioning schemes, you will find there are more than one copy of
> critical metadata.
> ext2 has a backup superblock GPT partition has a secondary header and
> table at the other end of the
> disk
>
> we really miss an on-disk backup of the LUKS header.

However the partition table does not have a backup at all.

It is a trade-off. Security-wise, an on-disk backup is a risk.
Makeing a backup manually is not that hard. Maybe a function
on cryptsetup or a contributed script could make it easier,
but that is about it. If you do, on the other hand, a
sector-wise backup of the encrypted partition, you not only
get the LUKS header, but also protect all the data against
a disk failure. Keeping in mind that disk failure roughly
has 5% annual probability per disk, that backup is
non-optional in the first place....

Arno

--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________

dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt