Hi,

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).


Regards,

Christian Spoo

Am 16.02.2008 um 01:08 schrieb Randy Barlow:

[EMAIL PROTECTED] 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
http://electronsweatshop.com
--
gentoo-security@lists.gentoo.org mailing list


Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to