Encrypted Root File System, Swap, etc...

[Warped_Dragon]

EDIT: Nevermind.... *sigh* forgot to *load* the loop-aes module......



Ok... first, sorry for dragging up an old thread, but I need a wee bit of help, and the gentoo forums have enough threads as it is ;)

I'm trying this out on my laptop ("this" being encrypting the entire filesystem and using a cd to boot). I've downloaded the latest loop-aes and compiled it, set up my kernel as the loop-aes readme specifies, compiled util-linux and gnupg with the patches that came with loop-aes.

Now, I've hit a bit of a stumbling block. Running "make tests" to ensure the loop-aes kernel module compiled correctly dies really soon. Why? There are no loop devices in my /dev directory. None. Nada. That's a problem, I'm thinking.... how do I go about adding them? My guess would be enabling loop devices in the kernel.... except that I'm not supposed to do that. I'm using 2.6.9-gentoo-r9 and udev, by the way.

Once I get this solved, I think I should be able to do this.

Oh, and another question. Since I had to compile my own util-linux and gnupg, how would I stop emerge from upgrading them (thus undoing my patched versions), and from recompiling the (or, what it thinks is the) current installed version, say on an emerge -e? I put them both in /etc/portage/package.mask, but I'm wondering if theres anything else to do as well. Removing them from my worldfile doesn't seem like a smart plan, as something will surely try to remerge them as dependencies....

[xbmodder]

with AES 256
Tiotest results for 4 concurrent io threads:
,----------------------------------------------------------------------.
| Item | Time | Rate | Usr CPU | Sys CPU |
+-----------------------+----------+--------------+----------+---------+
| Write 40 MBs | 1.2 s | 34.517 MB/s | 0.5 % | 65.1 % |
| Random Write 16 MBs | 0.2 s | 69.030 MB/s | 1.3 % | 117.9 % |
| Read 40 MBs | 0.2 s | 182.866 MB/s | 0.0 % | 173.2 % |
| Random Read 16 MBs | 0.1 s | 180.306 MB/s | 5.8 % | 183.4 % |
`----------------------------------------------------------------------'
Tiotest latency results:
,-------------------------------------------------------------------------.
| Item | Average latency | Maximum latency | % >2 sec | % >10 sec |
+--------------+-----------------+-----------------+----------+-----------+
| Write | 0.172 ms | 465.666 ms | 0.00000 | 0.00000 |
| Random Write | 0.069 ms | 170.724 ms | 0.00000 | 0.00000 |
| Read | 0.049 ms | 112.693 ms | 0.00000 | 0.00000 |
| Random Read | 0.035 ms | 40.625 ms | 0.00000 | 0.00000 |
|--------------+-----------------+-----------------+----------+-----------|
| Total | 0.094 ms | 465.666 ms | 0.00000 | 0.00000 |
`--------------+-----------------+-----------------+----------+-----------'


none
Tiotest results for 4 concurrent io threads:
,----------------------------------------------------------------------.
| Item | Time | Rate | Usr CPU | Sys CPU |
+-----------------------+----------+--------------+----------+---------+
| Write 40 MBs | 0.8 s | 52.141 MB/s | 0.8 % | 113.5 % |
| Random Write 16 MBs | 0.2 s | 88.695 MB/s | 1.1 % | 97.1 % |
| Read 40 MBs | 0.2 s | 192.995 MB/s | 2.9 % | 183.8 % |
| Random Read 16 MBs | 0.1 s | 178.302 MB/s | 2.3 % | 188.3 % |
`----------------------------------------------------------------------'
Tiotest latency results:
,-------------------------------------------------------------------------.
| Item | Average latency | Maximum latency | % >2 sec | % >10 sec |
+--------------+-----------------+-----------------+----------+-----------+
| Write | 0.139 ms | 295.947 ms | 0.00000 | 0.00000 |
| Random Write | 0.040 ms | 17.762 ms | 0.00000 | 0.00000 |
| Read | 0.056 ms | 105.013 ms | 0.00000 | 0.00000 |
| Random Read | 0.035 ms | 39.161 ms | 0.00000 | 0.00000 |
|--------------+-----------------+-----------------+----------+-----------|
| Total | 0.081 ms | 295.947 ms | 0.00000 | 0.00000 |
`--------------+-----------------+-----------------+----------+-----------'



both mounted on loops
not my root file system
a 100 MB ext3 file system

/proc/cpuinfo

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) MP 2400+
stepping : 1
cpu MHz : 2000.991
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3940.35

processor : 1
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) Processor
stepping : 1
cpu MHz : 2000.991
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3997.69

/proc/meminfo
MemTotal: 904452 kB
MemFree: 162224 kB
Buffers: 127052 kB
Cached: 292444 kB
SwapCached: 608 kB
Active: 405572 kB
Inactive: 290488 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 904452 kB
LowFree: 162224 kB
SwapTotal: 5012228 kB
SwapFree: 5009580 kB
Dirty: 62012 kB
Writeback: 0 kB
Mapped: 340320 kB
Slab: 30464 kB
Committed_AS: 402428 kB
PageTables: 2044 kB
VmallocTotal: 122804 kB
VmallocUsed: 25060 kB
VmallocChunk: 96176 kB






-----------------------------------------------------------
anything else post!

[echto]

Tape! Tar the data, pipe it to gpg, and write it to tape. Then keep the keys on a usb drive in your pocket.

hi all,

what a lovely thread, thanx for this one!!

my question for today is:

if i encrypt let's say f.e. /dev/hda und /dev/hdb (which is 200 gig altogether).....what would be the best method to do a full desaster recovery backup (encrypted) just in case one of the hdd's goes defect with the time ?

200 gig getting burned on 700 mb cd's would be to time consuming of course.

any ideas ?

Best Regards,

Alexander

[JloR]

Resurrecting an ooold thread :) One of the best in here though, imo.


I'm playing around with this, bought an 80gb hitachi disk for the laptop for this single purpose.. And I've read through most of the pages here, a few in the beginning and a few in the end.
But would I be wrong to assume that you no longer need to manually download and compile loop-aes and util-linux? Don't the newer loop-aes ebuilds do the patching for you?

loop-aes-3.1d depends on util-linux being built with the crypt feature in it.



I realize this might be a silly question, but I am slightly confused. And if I could get around the manual compile and patching, I would be happy happy - mainly because I wouldn't want to redo this every time I recompile a kernel.

[ozric]

Well I for one can't seem to make it. Does this procedure work with kernel 2.6.x?

In fact, I think I'm going crazy. Good thing I seem to learn something every time I mess up my system though

Can someone perhaps recomend a newer guide for loop-aes and encrypting the root partition (if its even needed, chances are that I am just not understanding this enough to make it werk)?

edit: Never mind, the problem for me was just pure lameness. I actually read the loop-aes readme, followed those instructions rather than Chadders' ones and it worked like a charm. Using Knoppix as a rescue system was very useful though, so thanks for that tip, Chad-man.

[selig]

Instead of compiling the loop-aes from the official package by hand, you can now use the ebuild. "emerge loop-aes" is sufficient. Other than that, I think this howto is still OK. But I would recommend not to leave the keys lying around on hard disk, take them with you on a floppy disk, USB stick or similar removable media. That way your data will be protected twice, because you need both the passphrase and encrypted key to be able to access the system. I will try and benchmark different ciphers today, but so far I like "serpent" the most.

[selig]

From what I have tried AES seems to be the fastest option (on my Pentium4-m 1.7GHz I get about 9MB/s for AES256 encryption), but the harddrive in my notebook is slow anyway, so I opted for Serpent 192 (about 7MB/s encryption on my hardware).
If you are using a journalling filesystem and you are journalling only filesystem metadata you can probably use an external journal to increase speed. (I am doing that and it works nicely) By journalling all data you get a security compromise, because someone could read the actual data from the journal (usually 32-128MB, which is not negligible). I do not think having access to metadata modifications provides a big security risk. It probably provides the potential attacker with some plaintext, which could maybe lower the security of AES encryption (its number of rounds is not too high..). On the other hand, AES is faster so you do not have to use tricks with external journal with it. I trust Serpent.