| 1 |
Hi, |
| 2 |
|
| 3 |
if you use dd like this: |
| 4 |
|
| 5 |
dd if=/dev/null bs=1 seek=1GB of=/whatever |
| 6 |
|
| 7 |
you're creating a so-called sparse file. Because of the seek- |
| 8 |
parameter, the kernel knows that the file actually doesn't contain any |
| 9 |
information between the first byte and the byte after the first GB in |
| 10 |
the file. In this case the kernel doesn't allocate the whole space for |
| 11 |
the file on your filesystem. But if you tell dd to explicitly write |
| 12 |
zeroes into the file the kernel must allocate all the space for the |
| 13 |
zeroes because it can't know that the zeroes are only placeholders. |
| 14 |
|
| 15 |
For speed reasons it's thus far better to create loopback images from / |
| 16 |
dev/null than /dev/zero. |
| 17 |
|
| 18 |
You will notice that the amount of used disk space will increase each |
| 19 |
time when you fill a byte in your sparse file. The kernel tries to |
| 20 |
optimize the sparse blocks so that the actual space consumption of the |
| 21 |
file is minimized. Note, that the same sparse file consumes different |
| 22 |
amounts of disk space when stored on different file system. Reiser3 is |
| 23 |
IMHO not best for storing such files. Ext3 and Reiser4 do better (the |
| 24 |
usually need less that 50 KB for storing such a file assuming it's |
| 25 |
really empty, Reiser3 could eat several MBytes because its algorithms |
| 26 |
for handling sparse files are not that good). |
| 27 |
|
| 28 |
|
| 29 |
Regards, |
| 30 |
|
| 31 |
Christian Spoo |
| 32 |
|
| 33 |
Am 16.02.2008 um 01:08 schrieb Randy Barlow: |
| 34 |
|
| 35 |
> bmicek@×××××××××.net wrote: |
| 36 |
>> I spent time about a year ago looking into good encryption. At that |
| 37 |
>> time, cryptsetup was the best bet. Its really easy to use. With |
| 38 |
>> cryptsetup, your best off encrypting an entire filesystem/partition |
| 39 |
>> so |
| 40 |
>> there are no restrictions regarding size. |
| 41 |
>> |
| 42 |
>> As far as ciphers, there are three popular ones that are 256 bits |
| 43 |
>> in the |
| 44 |
>> Linux kernel. You'll have to pick the one(s) you like best. |
| 45 |
>> Generally, |
| 46 |
>> everyone agrees Serpent is the strongest, followed by AES then |
| 47 |
>> followed |
| 48 |
>> by TwoFish. From my tests, performance of the algorithms is in |
| 49 |
>> reverse |
| 50 |
>> order (meaning TwoFish is the fastest). Linux is a bit behind last I |
| 51 |
>> checked regarding encription modes of operation and seems to only |
| 52 |
>> offer |
| 53 |
>> ECB or CBC. CBC is Chain Block Cipher and is based on an IV which is |
| 54 |
>> like an index into your media. The IV is used to encript a block of |
| 55 |
>> data so a previous identical block wont be identically encrypted. As |
| 56 |
>> far as your question regarding one-bit changes, a one bit change will |
| 57 |
>> have the effect you mentioned but only for one encrypted block. |
| 58 |
>> |
| 59 |
>> I'd recommend reading up on the ciphers to see what you like. |
| 60 |
>> There has |
| 61 |
>> been some talk about TwoFish being broken however I find it hard to |
| 62 |
>> believe. There has been a lot of talk about TrueCrypt on Linux. |
| 63 |
>> From |
| 64 |
>> what I can tell, it seems a bit more advanced and supports different |
| 65 |
>> (more modern?) modes of encryption. |
| 66 |
> |
| 67 |
> Thanks for the reply Brian! In a course I am taking this semester, we |
| 68 |
> have learned the nitty gritty of AES, and I think I am pretty happy |
| 69 |
> with |
| 70 |
> that one given a long enough key (256 is way plenty!) I have been |
| 71 |
> playing around with the creation of the file for the loopback block |
| 72 |
> device for dm-crypt, and I have learned some surprising things about |
| 73 |
> filesystems. Can anybody explain the following to me? |
| 74 |
> |
| 75 |
> If I create a file like this: |
| 76 |
> |
| 77 |
> dd if=/dev/zero bs=1000000000 of=/path/to/crytped/file |
| 78 |
> |
| 79 |
> it makes a file that takes up 1 GB of hard drive space. It takes a |
| 80 |
> while to write to disk, and you will notice that the file is 1 GB with |
| 81 |
> ls -l and you will also notice a change in the space for the partition |
| 82 |
> using df. |
| 83 |
> |
| 84 |
> If I create a file like this: |
| 85 |
> |
| 86 |
> dd bs=1 seek=1GB if=/dev/null of=/path/to/crypted/file |
| 87 |
> |
| 88 |
> it makes a file that reports itself to be 1 GB long by ls -l, but |
| 89 |
> doesn't seem to write 1 GB to the disk. Also, df doesn't report 1 GB |
| 90 |
> less than before you run the command. |
| 91 |
> |
| 92 |
> What's happening here? I had assumed before I did this that the |
| 93 |
> output |
| 94 |
> of ls -l is the actual number of bits consumed by a file, but that |
| 95 |
> doesn't seem to be the case anymore. |
| 96 |
> |
| 97 |
> I created a file using the second command, and now as I copy files |
| 98 |
> into |
| 99 |
> it I can see the disk space going down bit by bit. This is really |
| 100 |
> what |
| 101 |
> I wanted in the first place, but I am just confused as to what is |
| 102 |
> really |
| 103 |
> going on. Could anybody explain, please? |
| 104 |
> |
| 105 |
> -- |
| 106 |
> Randy Barlow |
| 107 |
> http://electronsweatshop.com |
| 108 |
> -- |
| 109 |
> gentoo-security@l.g.o mailing list |
| 110 |
> |
Archives