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