Gentoo Archives: gentoo-security

From: Samuel Halicke <tuscantwelve@×××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Encrypting a user home folder on a laptop
Date: Sat, 16 Feb 2008 03:08:36
In Reply to: Re: [gentoo-security] Encrypting a user home folder on a laptop by Randy Barlow
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


On Feb 15, 2008, at 6:08 PM, Randy Barlow wrote:

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