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