[dm-crypt] Corrupted luks partition, help needed
malakudi at gmail.com
Fri Jun 4 08:05:54 CEST 2010
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
On Fri, Jun 4, 2010 at 1:07 AM, Arno Wagner <arno at wagner.name> 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
> >>> 128KB keyslot is actually the 32byte master key AF-split to 128KB and
> >>> 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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno at wagner.name
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25
> 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 at saout.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt