<HTML>
Here are some other quick reads that appear to be accurate:<BR>
Serpent Cipher: http://en.wikipedia.org/wiki/Serpent_%28cipher%29<BR>
From Serpent's site - a claim it is stronger than AES: http://www.cl.cam.ac.uk/~rja14/serpent.html<BR>
AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard<BR>
Two Fish: http://en.wikipedia.org/wiki/TwoFish<BR>
Bruce Schneier on Two Fish being far from broken: http://www.schneier.com/blog/archives/2005/11/twofish_cryptan.html<BR>
Cipher Modes: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation<BR>
Electronic Code Book (ECB): http://en.wikipedia.org/wiki/Electronic_code_book<BR>
Chain Block Cipher (CBC): http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation<BR>
True Crypt: http://en.wikipedia.org/wiki/True_Crypt<BR>
True Crypt's Site: http://www.truecrypt.org/<BR>
<BR>
Brian Micek<BR>
<BR>
On Friday February 15 2008 10:06 pm, Samuel Halicke wrote:<BR>
> Read Introduction To Algorithms and get the MIT open courseware for<BR>
> the book from their site or iTunes Univ.<BR>
><BR>
> At least you get a start that way<BR>
><BR>
> Sam<BR>
><BR>
> On Feb 15, 2008, at 6:08 PM, Randy Barlow wrote:<BR>
> > bmicek@... wrote:<BR>
> >> I spent time about a year ago looking into good encryption. At that<BR>
> >> time, cryptsetup was the best bet. Its really easy to use. With<BR>
> >> cryptsetup, your best off encrypting an entire filesystem/partition<BR>
> >> so<BR>
> >> there are no restrictions regarding size.<BR>
> >><BR>
> >> As far as ciphers, there are three popular ones that are 256 bits<BR>
> >> in the<BR>
> >> Linux kernel. You'll have to pick the one(s) you like best.<BR>
> >> Generally,<BR>
> >> everyone agrees Serpent is the strongest, followed by AES then<BR>
> >> followed<BR>
> >> by TwoFish. From my tests, performance of the algorithms is in<BR>
> >> reverse<BR>
> >> order (meaning TwoFish is the fastest). Linux is a bit behind last I<BR>
> >> checked regarding encription modes of operation and seems to only<BR>
> >> offer<BR>
> >> ECB or CBC. CBC is Chain Block Cipher and is based on an IV which is<BR>
> >> like an index into your media. The IV is used to encript a block of<BR>
> >> data so a previous identical block wont be identically encrypted. As<BR>
> >> far as your question regarding one-bit changes, a one bit change will<BR>
> >> have the effect you mentioned but only for one encrypted block.<BR>
> >><BR>
> >> I'd recommend reading up on the ciphers to see what you like.<BR>
> >> There has<BR>
> >> been some talk about TwoFish being broken however I find it hard to<BR>
> >> believe. There has been a lot of talk about TrueCrypt on Linux.<BR>
> >> From<BR>
> >> what I can tell, it seems a bit more advanced and supports different<BR>
> >> (more modern?) modes of encryption.<BR>
> ><BR>
> > Thanks for the reply Brian! In a course I am taking this semester, we<BR>
> > have learned the nitty gritty of AES, and I think I am pretty happy<BR>
> > with<BR>
> > that one given a long enough key (256 is way plenty!) I have been<BR>
> > playing around with the creation of the file for the loopback block<BR>
> > device for dm-crypt, and I have learned some surprising things about<BR>
> > filesystems. Can anybody explain the following to me?<BR>
> ><BR>
> > If I create a file like this:<BR>
> ><BR>
> > dd if=/dev/zero bs=1000000000 of=/path/to/crytped/file<BR>
> ><BR>
> > it makes a file that takes up 1 GB of hard drive space. It takes a<BR>
> > while to write to disk, and you will notice that the file is 1 GB with<BR>
> > ls -l and you will also notice a change in the space for the partition<BR>
> > using df.<BR>
> ><BR>
> > If I create a file like this:<BR>
> ><BR>
> > dd bs=1 seek=1GB if=/dev/null of=/path/to/crypted/file<BR>
> ><BR>
> > it makes a file that reports itself to be 1 GB long by ls -l, but<BR>
> > doesn't seem to write 1 GB to the disk. Also, df doesn't report 1 GB<BR>
> > less than before you run the command.<BR>
> ><BR>
> > What's happening here? I had assumed before I did this that the<BR>
> > output<BR>
> > of ls -l is the actual number of bits consumed by a file, but that<BR>
> > doesn't seem to be the case anymore.<BR>
> ><BR>
> > I created a file using the second command, and now as I copy files<BR>
> > into<BR>
> > it I can see the disk space going down bit by bit. This is really<BR>
> > what<BR>
> > I wanted in the first place, but I am just confused as to what is<BR>
> > really<BR>
> > going on. Could anybody explain, please?<BR>
> ><BR>
> > --<BR>
> > Randy Barlow<BR>
> > http://electronsweatshop.com<BR>
> > --<BR>
> > gentoo-security@g.o mailing list<BR>
<BR>
</HTML>
<BR>--
gentoo-security@g.o mailing list
|
