On Sun, December 30, 2012 20:45, Arno Wagner wrote: > 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@xxxxxxxxxxx> 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. AFAIK as of 2TB it's NTFS with the my book and the 4 TB one certainly has a GPT aswell. > >> > > 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. Wouldn't that be ext5 then anyway, since the change is incompatible (touching the main metadata)with current versions? That feels liek ressurecting the dead ;-). > >> 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. Most paranoid and 'safe' way. > >> 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. Well it is not a filesystem type, but partition type. Then again, as linux can access a whole bunch of types (including different label styles) this could at most be checked within tools (i.e. mdadm ignores everything except raid partition types). On the other hand, it is perfectly okay to not slice the disk and put LVM, MD(raid), luks or even a fs directly onto the device. If that is a wise decision is another question though. Think of the GPT, where usually a protective mbr is created, so that low level tools keep their finger off what they don't know, partition in general could be handled by tools this way. Speaking of which, there's GUIDs for LVM, RAID, FSDATA but not for LUKS/cryptsetup so far. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
