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:

> bmicek@... 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
> -- 
> gentoo-security@g.o mailing list
>

-- 
gentoo-security@g.o mailing list