Gentoo Archives: gentoo-security

From: Christian Spoo <mail@××××××××××××××.info>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Encrypting a user home folder on a laptop
Date: Sat, 16 Feb 2008 07:48:44
In Reply to: Re: [gentoo-security] Encrypting a user home folder on a laptop by Randy Barlow

if you use dd like this:

dd if=/dev/null bs=1 seek=1GB of=/whatever

you're creating a so-called sparse file. Because of the seek- 
parameter, the kernel knows that the file actually doesn't contain any  
information between the first byte and the byte after the first GB in  
the file. In this case the kernel doesn't allocate the whole space for  
the file on your filesystem. But if you tell dd to explicitly write  
zeroes into the file the kernel must allocate all the space for the  
zeroes because it can't know that the zeroes are only placeholders.

For speed reasons it's thus far better to create loopback images from / 
dev/null than /dev/zero.

You will notice that the amount of used disk space will increase each  
time when you fill a byte in your sparse file. The kernel tries to  
optimize the sparse blocks so that the actual space consumption of the  
file is minimized. Note, that the same sparse file consumes different  
amounts of disk space when stored on different file system. Reiser3 is  
IMHO not best for storing such files. Ext3 and Reiser4 do better (the  
usually need less that 50 KB for storing such a file assuming it's  
really empty, Reiser3 could eat several MBytes because its algorithms  
for handling sparse files are not that good).


Christian Spoo

Am 16.02.2008 um 01:08 schrieb Randy Barlow:

> bmicek@×××××××××.net wrote: >> I spent time about a year ago looking into good encryption. At that >> time, cryptsetup was the best bet. Its really easy to use. With >> cryptsetup, your best off encrypting an entire filesystem/partition >> so >> there are no restrictions regarding size. >> >> As far as ciphers, there are three popular ones that are 256 bits >> in the >> Linux kernel. You'll have to pick the one(s) you like best. >> Generally, >> everyone agrees Serpent is the strongest, followed by AES then >> followed >> by TwoFish. From my tests, performance of the algorithms is in >> reverse >> order (meaning TwoFish is the fastest). Linux is a bit behind last I >> checked regarding encription modes of operation and seems to only >> offer >> ECB or CBC. CBC is Chain Block Cipher and is based on an IV which is >> like an index into your media. The IV is used to encript a block of >> data so a previous identical block wont be identically encrypted. As >> far as your question regarding one-bit changes, a one bit change will >> have the effect you mentioned but only for one encrypted block. >> >> I'd recommend reading up on the ciphers to see what you like. >> There has >> been some talk about TwoFish being broken however I find it hard to >> believe. There has been a lot of talk about TrueCrypt on Linux. >> From >> what I can tell, it seems a bit more advanced and supports different >> (more modern?) modes of encryption. > > Thanks for the reply Brian! In a course I am taking this semester, we > have learned the nitty gritty of AES, and I think I am pretty happy > with > that one given a long enough key (256 is way plenty!) I have been > playing around with the creation of the file for the loopback block > device for dm-crypt, and I have learned some surprising things about > filesystems. Can anybody explain the following to me? > > If I create a file like this: > > dd if=/dev/zero bs=1000000000 of=/path/to/crytped/file > > it makes a file that takes up 1 GB of hard drive space. It takes a > while to write to disk, and you will notice that the file is 1 GB with > ls -l and you will also notice a change in the space for the partition > using df. > > If I create a file like this: > > dd bs=1 seek=1GB if=/dev/null of=/path/to/crypted/file > > it makes a file that reports itself to be 1 GB long by ls -l, but > doesn't seem to write 1 GB to the disk. Also, df doesn't report 1 GB > less than before you run the command. > > What's happening here? I had assumed before I did this that the > output > of ls -l is the actual number of bits consumed by a file, but that > doesn't seem to be the case anymore. > > I created a file using the second command, and now as I copy files > into > it I can see the disk space going down bit by bit. This is really > what > I wanted in the first place, but I am just confused as to what is > really > going on. Could anybody explain, please? > > -- > Randy Barlow > > -- > gentoo-security@l.g.o mailing list >


File name MIME type
PGP.sig application/pgp-signature