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