[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

Arno Wagner arno at wagner.name
Sun Dec 30 20:45:50 CET 2012

On Sun, Dec 30, 2012 at 11:59:56AM -0500, Emily Williams wrote:
> On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno at wagner.name> wrote:
> > On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
> > > I think these are the 2 most common sources, when something like this
> > > happens.
> > >
> > > It would be interesting to know though:
> > >
> > > Did the device ever hold an ext filesystem?
> > > What was done before creating the luks container?
> >
> The disk before luksFormat was a new-out-of-the-box WD 4TB "My Book"
> external USB 3 hard drive. Nothing at all had been done to it before being
> attached to the already-running system. The already-running system was
> running Debian GNU/Linux Squeeze on x86_64.
> I assume it had FAT32 formatting before the luksFormat, but I don't know
> for sure. But I am 100% sure it wouldn't have had any kind of extX
> formatting.

With 4TB, it should have had an NTFS filesystem on it.
> >  > I wonder how fsck checks for a superblock. I still assume, that chances
> > of
> > > having encrypted data in the right block on disk looking like a correct
> > > ext-superblock is next to zero.
> >
> > The ext2 superblock magic number seems to be 0xEF53. That is a bit
> > short but still only gives something like 1 in 65536 probability of
> > misdetection in encrypted data. I think we can rule that out
> > for the moment.
> That actually seems like a pretty big chance to me. esp. if a hard drive
> manufacturer happens to have shipped a hard drive model where each hard
> drive has this problem.

It is not. First, the signature would need to turn up in the encrypted 
data and that is different for each LUKS container. In addition,
the first superblock is in an area that newer versions of cryptsetup
overwrite with zeros.
> I wonder how many different models of hard drive are produced every year /
> from that what the chances are of this being a "problem by default" on a
> large number of hard drives over say a 10-year period.

Basically none. The HDD vendors do not write random data to their drives.
They either come zeroed of with a filesystem on them (USB drives).

> Is there some reason using, say, an order of magnitude (or even two orders)
> more data for a magic number would cause some kind of issue? The actual
> amount of data vs. the size of any modern hard drive would seem to me to be
> pretty trivial.

I agreee, that ist is a bit short. Anybody with a crypto background would
want at least 128 bit (16 bytes) and better 256 bit for magic numbers.
But it is out-of-scope for cryptsetup and I doubt we can have much
influence on the ext<x> designers.
> Thanks re: wipefs (in another person's response), seems like a better and
> more complete solution than what I did, which was something like dd
> if=/dev/zero of=/dev/sdX count=10000. 

No, the zero overwrite is better. Its only problem is that it is slow.

> Although based on other people it
> sounds like doing wipefs + dd at start of both drive and partiton + dd at
> end of both drive and partition (which I'm guessing would just need to be
> calculated and then a seek/skip option to dd used, as I can't see any
> option that will let dd work backwards) would be the most paranoid /
> complete way to go.

The most paranoid is one complete zero-overwrite. 

> One thing no one has mentioned that may add an additional bit of safety -
> while researching this, I found someone saying that the filesystem type as
> set in [gf]disk is always ignored by Linux. (Perhaps this only holds true
> for non-"fd "partitions?)

No idea. But that way madness lies, I think.

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

More information about the dm-crypt mailing list