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