Mailing List Archive

Hi
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.

Brian



On Friday February 15 2008 6:09 pm, Randy Barlow wrote:
> I am probably being paranoid, but I'd like to encrypt my /home/username
> folder on my laptop. I tried EncFS using [1], but KDE didn't seem to
> work under that setup because of the restriction that the filesystem
> doesn't support hardlinks. So now I am playing around with [2]. The
> only problem I have here is that it seems like I have to know in advance
> what size I want to use for my home folder (I am using a file as a
> loopback device rather than a partition, mostly because I already have a
> system up and don't want to mess with resizing partitions). Is there
> any way to resize the loopback device on the fly, or do you just have to
> create a new one and copy the files into it every time you need to resize?
>
> Another question I have: I am pretty new to ciphers. One thing I have
> learned is that the avalanche effect is desirable, meaning that one bit
> flipped in the plaintext should cause about half of the ciphertext bits
> to flip. Does the dm-crypt setup have much correlation between
> encryption blocks to where this avalanche effect would change the whole
> file, or just a few encryption blocks? To illustrate, I'm looking to
> encrypt probably something like 40 GB of data. If I change 1 bit
> somewhere in my plaintext, how many bytes of that 40 GB of total data on
> my loopback device should I expect that bit flip to have an effect on?
>
> Thanks for any enlightenment you can offer!
>
> [1] http://gentoo-wiki.com/HOWTO_Encrypt_Your_Home_Directory_Using_EncFS
> [2] http://gentoo-wiki.com/SECURITY_dmcrypt
>
> --
> Randy Barlow
> http://electronsweatshop.com


-- gentoo-security@lists.gentoo.org mailing list

bmicek@speakeasy.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
http://electronsweatshop.com
--
gentoo-security@lists.gentoo.org mailing list

http://en.wikipedia.org/wiki/Sparse_file


On Fri, 2008-02-15 at 19:08 -0500, Randy Barlow wrote:
> bmicek@speakeasy.net wrote:
> > I spent time about a year ago looking into good encryption. At that
> >...
....
> 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
--
William Kenworthy <billk@iinet.net.au>
Home in Perth!
--
gentoo-security@lists.gentoo.org mailing list

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@speakeasy.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
> http://electronsweatshop.com
> --
> gentoo-security@lists.gentoo.org mailing list
>

--
gentoo-security@lists.gentoo.org mailing list

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:
> > bmicek@speakeasy.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
> > http://electronsweatshop.com
> > --
> > gentoo-security@lists.gentoo.org mailing list


-- gentoo-security@lists.gentoo.org mailing list

Hi,

if you use dd like this:

dd if=/dev/null bs=1 seek=1GB of=/whatever

you're creating a so-called sparse file. Because of the seek-
parameter, the kernel knows that the file actually doesn't contain any
information between the first byte and the byte after the first GB in
the file. In this case the kernel doesn't allocate the whole space for
the file on your filesystem. But if you tell dd to explicitly write
zeroes into the file the kernel must allocate all the space for the
zeroes because it can't know that the zeroes are only placeholders.

For speed reasons it's thus far better to create loopback images from /
dev/null than /dev/zero.

You will notice that the amount of used disk space will increase each
time when you fill a byte in your sparse file. The kernel tries to
optimize the sparse blocks so that the actual space consumption of the
file is minimized. Note, that the same sparse file consumes different
amounts of disk space when stored on different file system. Reiser3 is
IMHO not best for storing such files. Ext3 and Reiser4 do better (the
usually need less that 50 KB for storing such a file assuming it's
really empty, Reiser3 could eat several MBytes because its algorithms
for handling sparse files are not that good).


Regards,

Christian Spoo

Am 16.02.2008 um 01:08 schrieb Randy Barlow:

> bmicek@speakeasy.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
> http://electronsweatshop.com
> --
> gentoo-security@lists.gentoo.org mailing list
>

On Fri, 2008-02-15 at 18:09 -0500, Randy Barlow wrote:
> I am probably being paranoid, but I'd like to encrypt my /home/username
> folder on my laptop. I tried EncFS using [1], but KDE didn't seem to
> work under that setup because of the restriction that the filesystem
> doesn't support hardlinks. So now I am playing around with [2]. The
> only problem I have here is that it seems like I have to know in advance
> what size I want to use for my home folder (I am using a file as a
> loopback device rather than a partition, mostly because I already have a
> system up and don't want to mess with resizing partitions). Is there
> any way to resize the loopback device on the fly, or do you just have to
> create a new one and copy the files into it every time you need to resize?
>
> Another question I have: I am pretty new to ciphers. One thing I have
> learned is that the avalanche effect is desirable, meaning that one bit
> flipped in the plaintext should cause about half of the ciphertext bits
> to flip. Does the dm-crypt setup have much correlation between
> encryption blocks to where this avalanche effect would change the whole
> file, or just a few encryption blocks? To illustrate, I'm looking to
> encrypt probably something like 40 GB of data. If I change 1 bit
> somewhere in my plaintext, how many bytes of that 40 GB of total data on
> my loopback device should I expect that bit flip to have an effect on?
>
> Thanks for any enlightenment you can offer!
>
> [1] http://gentoo-wiki.com/HOWTO_Encrypt_Your_Home_Directory_Using_EncFS
> [2] http://gentoo-wiki.com/SECURITY_dmcrypt
>

1. dmcrypt allows online resizing. If it's a loopback device, just
expand it with dmcrypt, then the FS on top of it. If it's a partition/
logical volume, you have to expand this at first.

2. With good ciphers, for example aes-lrw-benbi:sha256 (keysize 384)
dmcrypt should be fine. But you have to understand that it's encrypted
block by block. If you change one bit, only the block it's within is
changed. dmcrypt doesn't know about files and filesystems, it just knows
blocks. However, this doesn't mean that two blocks identical in
plaintext look exactly the same when encrypted. The encryption changes
after every block.

By the way, I use pam_mount and cryptsetup-luks to mount my encrypted
home-partition with my login password on the fly. If you want a short
howto and my configuration, just ask, I can answer again in 10 hours
(Sat Feb 16 19:00:00 UTC).

On Saturday 16 February 2008, Randy Barlow wrote:
> I am probably being paranoid, but I'd like to encrypt my /home/username
> folder on my laptop. I tried EncFS using [1], but KDE didn't seem to
> work under that setup because of the restriction that the filesystem
> doesn't support hardlinks. So now I am playing around with [2]. The
> only problem I have here is that it seems like I have to know in advance
> what size I want to use for my home folder (I am using a file as a
> loopback device rather than a partition, mostly because I already have a
> system up and don't want to mess with resizing partitions). Is there
> any way to resize the loopback device on the fly, or do you just have to
> create a new one and copy the files into it every time you need to resize?
I have some old notes lying around about this.

If you're working without partitions and using ext something like the
following should work. Note it is not on the fly, but OTOH you don't have to
start from scratch either.

Unmount loopback device.

Enlarge protected_file
dd if=/dev/urandom bs=1024k count=10 >> protected_file

Setup loopdevice
losetup /dev/loop6 protected_file

Setup the crypto device
cryptsetup -y create testcrypt /dev/loop6

Now enlarge the filesystem
fsck.ext2 -f /dev/mapper/testcrypt

Though you should test it before running it on your home dir (and report back
here)!

HTH.

--
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
--
gentoo-security@lists.gentoo.org mailing list

On Saturday 16 February 2008 10.04.30 Florian Philipp wrote:
[...]
> By the way, I use pam_mount and cryptsetup-luks to mount my encrypted
> home-partition with my login password on the fly. If you want a short
> howto and my configuration, just ask, I can answer again in 10 hours
> (Sat Feb 16 19:00:00 UTC).

Please do, atleast I'm curious.

/BR
Naga
--
gentoo-security@lists.gentoo.org mailing list

Hello everyone,

I've been using dm-crypt with twofish-lrw-benbi:ripemd160 for (swap
and /tmp) because, if I understand correctly, Twofish is more
optimized in the Linux kernel than AES (and therefore faster). I've
been thinking of using AES on /home.
One thing I don't understand is the term "benbi". Does this have
something to do with IV generation?

One last thing. I've heard that LRW will be replaced with XTS. [1]
IIRC correctly, the XTS cipher mode isn't in the Linux kernel yet?
Also, from what I've read, the problems with LRW boil down to a
"traitor tracing" problem, that repeated physical access to a drive is
needed, and even then one could theoretically only confirm the
presence of a known plaintext. Am I getting this right?

[1] http://en.wikipedia.org/wiki/IEEE_P1619#LRW_issue

Sincerely,
Mansour Moufid
--
gentoo-security@lists.gentoo.org mailing list

On Sat, 2008-02-16 at 21:34 +0100, Naga Toro wrote:
> On Saturday 16 February 2008 10.04.30 Florian Philipp wrote:
> [...]
> > By the way, I use pam_mount and cryptsetup-luks to mount my encrypted
> > home-partition with my login password on the fly. If you want a short
> > howto and my configuration, just ask, I can answer again in 10 hours
> > (Sat Feb 16 19:00:00 UTC).
>
> Please do, atleast I'm curious.
>
> /BR
> Naga

Okay,

I think I can skip the creation of a cryptsetup-luks partition (or
whatever). It should be clear that you need to use your login password.

The next step would be to emerge pam_mount.

Then edit /etc/security/pam_mount.conf.xml

The relevant part to add is:

<volume
user="dsl"
fstype="crypt"
path="/dev/vg/home_dsl"
mountpoint="/home/dsl"
options="async,noatime,exec"
/>
<volume
user="dsl"
fstype="reiserfs"
path="/dev/mapper/_dev_mapper_vg-home_dsl"
mountpoint="/home/dsl"
options="defaults,async,noatime,exec"
/>

above </pam_mount>

As you can see, "dsl" is my user name and /dev/vg/home_dsl my encrypted
home volume. In case I've missed something in this file, I've attached
it gzip-compressed.

Then you need to edit /etc/pam.d/system-auth:

#%PAM-1.0

auth required pam_env.so
auth optional pam_mount.so
auth sufficient pam_unix.so likeauth nullok use_first_pass
auth required pam_deny.so use_first_pass

account required pam_unix.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2
ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session optional pam_mount.so

(or something similar)

I think the relevant parts are "use_first_pass" and "pam_mount" in
"auth" and "session".

I don't say that my setup is perfect. It was a huge trial and error
phase to get it working.

Of course, you need to use pam for it to work but that's the default
setting on Gentoo. Please check your USE-flags for pam and your
sshd_config for usage of pam.

If it doesn't work, try it without XDM/KDM/GDM (I use XDM but all should
work). pam should write some debug information. Then search /dev/mapper
for something that looks like your home-partition's mapping.

2008/2/16, Randy Barlow <randy@electronsweatshop.com>:

> Thanks for any enlightenment you can offer!
>
> [1] http://gentoo-wiki.com/HOWTO_Encrypt_Your_Home_Directory_Using_EncFS
> [2] http://gentoo-wiki.com/SECURITY_dmcrypt
>

Just being curious - what prevents You from using encrypted LVM
parition for home ?

--
Wojciech Ziniewicz
Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;fl
ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
ct;umount;makeclean; zip;split;done;exit:xargs!!;)}
--
gentoo-security@lists.gentoo.org mailing list

Wojciech Ziniewicz wrote:
> 2008/2/16, Randy Barlow <randy@electronsweatshop.com>:
>
>> Thanks for any enlightenment you can offer!
>>
>> [1] http://gentoo-wiki.com/HOWTO_Encrypt_Your_Home_Directory_Using_EncFS
>> [2] http://gentoo-wiki.com/SECURITY_dmcrypt
>>
>
> Just being curious - what prevents You from using encrypted LVM
> parition for home ?

Nothing prevents me per se - this is just an existing system that I'd
rather not repartition if I can get away with it. Right now /home is
part of / so I'm trying to avoid changing that. So far it seems like I
might need to change it anyway though...

--
Randy Barlow
http://electronsweatshop.com
--
gentoo-security@lists.gentoo.org mailing list

Randy Barlow wrote:
> I am probably being paranoid, but I'd like to encrypt my /home/username
> folder on my laptop.

just another point: you should think about encrypting at least /tmp and swap
too, because temporary data will be stored there and if your home dir is
encrypted but those two are not one could simply read your data from there.
Have a look at this forum thread for the setup. because it uses random keys
you don't have to enter a passphrase at bootup:
http://forums.gentoo.org/viewtopic-t-298001-highlight-encrypt+ramdisk.html
--
gentoo-security@lists.gentoo.org mailing list

On Sun, 2008-02-17 at 11:53 +0100, Florian Sowade wrote:
> Randy Barlow wrote:
> > I am probably being paranoid, but I'd like to encrypt my /home/username
> > folder on my laptop.
>
> just another point: you should think about encrypting at least /tmp and swap
> too, because temporary data will be stored there and if your home dir is
> encrypted but those two are not one could simply read your data from there.
> Have a look at this forum thread for the setup. because it uses random keys
> you don't have to enter a passphrase at bootup:
> http://forums.gentoo.org/viewtopic-t-298001-highlight-encrypt+ramdisk.html

It's even worse when you hibernate because your whole RAM-content
(including disk caches from your encrypted home-partition) is written to
disk and encryption is not so easy because you have to ask for the
pass-phrase on resuming in early userspace. Look here for how to solve
it:
http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS

I fear I'll have to spend my Easter holidays converting my system with
that guide.

On Saturday 16 February 2008 23.09.05 Florian Philipp wrote:
> On Sat, 2008-02-16 at 21:34 +0100, Naga Toro wrote:
> > Please do, atleast I'm curious.

> Okay,
[...]

Thanks!
--
gentoo-security@lists.gentoo.org mailing list

Hi

Here, I'm using loop-AES to crypt all my filesystem. It's really
great and fast. (Actually I run some VMs in my machine...)

Some links:
http://www-curri.u-strasbg.fr/documentation/calcul/doc/ProPack/3SP1/docs/HOWTO/html/Encrypted-Root-Filesystem-HOWTO.html

Basically, you just need a partition or a file that you map using
loopsetup and then mount. ( But you need the kernel support and a new
Util-linux distribution. Nothing hard for a gentoo user)

[]'s

--
##
#Luiz Otavio Duarte
##
--
gentoo-security@lists.gentoo.org mailing list