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.
> I wonder how fsck checks for a superblock. I still assume, that chances ofThe ext2 superblock magic number seems to be 0xEF53. That is a bit
> having encrypted data in the right block on disk looking like a correct
> ext-superblock is next to zero.
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.
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.
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.
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. 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.
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?)
So I've taken to setting my encrypted partitions to "NetBSD Encrypted" (a905), so when I look at the partition tables I'm reminded that there actually isn't a Linux filesystem on the device itself, but rather something that is encrypted that becomes a Linux filesystem via /dev/mapper/X after cryptosetup luksOpen happens.
(I don't use NetBSD, so no chance of confusion there :-)
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
