M/B SuperMicro X7SBE-О LGA775, i3210
CPU Intel(R) Xeon(R) X3370 @ 3.00GHz
RAID controller 3ware 9690SA-8I (OEM) PCI-E x8
HDD 73 Gb SAS Hitachi 15000rpm 16Mb 6 pcs. in RAID10
RAM 2Gb ECC CL6 x 4

I have about 330 – 350 MB/s secquental reading and writing, but with ecryption speed fall to ~120 MB/s writing and ~99MB/s reading.

By using this (http://www.holtznet.de/luks/) small test I saw that max enryption speed can be reached on my system with this settings: “-c aes-xts-plain -s 256″
write: 134 MB/s
read: 144 MB/s
but this values is terribly slow, its about 280% slower than without encryption.

Therefore when disk perfomance is above some speed, “bottleneck” is CPU perfomance and the fact that dm-crypt uses only one core.

Very useful information on the dm-crypt and related issues.
http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2006-11/msg00018.html

By now I spend about a week, and still didn’t found any decision how increase encryption speed.

Any suggestion?

I would suggest that one good reason for encrypting the root filesystem on a laptop is to prevent installation of a trojan horse that could subsequently steal/hijack/whatever -anything- you do on the laptop.

Scenario
(1) You leave your laptop in a hotel room, office, whatever.
(2) An attacker gains access via social engineering, forcible entry, whatever.
(3) The attacker installs a trojan in the boot sequence of the laptop. He could do this even w/ BIOS passwords, login passwords, etc. All he has to do is remove the hard drive from the laptop, plug it into a USB device and then access it as an additional hard drive on another laptop. He wouldn’t even need to load your Linux system–he just needs to be able to read/write whatever type of filesystem your root is.
(4) He puts everything back and leaves.
(5) Now you load your laptop. Even w/ encrypted home, once you’ve mounted /home he has access to it all via his trojan, and obviously he could get whatever you do on the web.

You could halt this process at steps (1)/(2) by always maintaining physical security of your laptop. This is probably the cheapest/easiest solution in most cases, but might not be possible in your situation.

Or, you could halt this process at step (3) by encrypting your root filesystem. Arguably, in order for this to work, you’d probably need to keep your /boot on a USB key which would always be required for booting the computer. Otherwise, your unencrypted /boot could be hijacked.

My two cents.

I was wondering what you used to generate your graphs. It looks a bit too polished to be gnuplot. Did whatever you used just slurp up, for example, the bonnie++ .csv results, or did you have to write a script to do the heavy lifting?

Yes, big files would be a tough job (I feel your pain, I’ve lost my data several times before).

Small files are easier – I lost 6 hours of work once when I accidentally deleted a file (on an ext3 partition) and was able to recover it in about 60 minutes using nothing but grep and an old copy of the file.

Cheers,

Darren

I agree ^_^

But – I assure you – “he” must be a VERY dedicated attacker. I lost myself big chunks of data multiple times, and I was never able of recover it. Maybe for smaller files could really be a lot simpler.

Thanks again

-Jaba

Glad I could be of assistance and thanks for the link, I didn’t know ext3 did this.

It’s interesting to note that *all* of the file remains on disk until it gets overwritten – what’s being deleted is the list of locations where the file is (or was) stored. While this makes undeletion much harder, a dedicated attacker can still recover the entire file with enough time, provided another file hasn’t overwritten it. The filesystem makes the attacker’s job easier by attempting to write the file to disk in consecutive blocks (for best performance). Smaller files especially will tend to be kept intact, making them especially vulnerable.

Cheers,

Darren

GREAT – GREAT – GREAT

Thank you so much – that was a simply perfect answer, clear and complete. You’ve completely answered all my doubts – thanks!.
Now I now how to act to secure my work – best of all, I know WHY.

By now, my configuration is:
1. no swap
2. tmpfs for all temporary dirs
3. auto-clean firefox cache/cookies/history on shutdown
4. Desktop folder encrypted, work folder as subdirectory
5. work backups on encrypted secure digital

I feel enough safe for my purpose, and works like a charm on my eeepc – which anyway wasn’t designed for large files or photo/video editing thanks a lot, you’ve been very clear about leftover fragments.

Thanks everybody for your support – and to Waine for the place
Hope this discussion will be useful to many

-Jaba

ps btw, the inode/data part isn’t really as simple as shown…
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
go down to Q: How can I recover (undelete) deleted files from my ext3 partition?
ext3 does enough the trick in the background… not safe if someone is stealing your pc looting for data, but safe enough for common use.

Hopefully I can answer your question about why / should be encrypted:

1) Leftover file fragments:
Lets say you’re working on a private document on your desktop. You finish for the day and copy this document to your secure partition, then unmount it. You delete the original document and your data is safe.

Or is it?

Deleting a file only removes the inode (the filesystem’s index to where the file is stored). The actual (private) data is still on the disk, and some trivial computer forensics (google photorec) will recover the deleted file.

If you know what you’re doing, you might securely wipe the file instead of just deleting it, because a secure wipe destroys the data on disk before removing the inode, but even that won’t guarantee your safety. Many programs write temporary files in the course of operation, and they don’t always put their files in /tmp. If the environment variable TMPDIR is set the program will often prefer that directory (an attacker could trick you into setting TMPDIR perhaps). vim will write a .swp file in the same directory as the file you are editing. gimp will store its tile cache in ~/.gimp*/ etc etc. You can bet these files are *not* securely wiped and fragments of your original file can still be recovered (possibly the whole file).

2) secure by default
You could possibly keep track of all these messy temp files and make sure you wipe them all the time, but it takes discipline, even for trivial cases. If you screw up once your data could be leaked. Encrypting the root reverses the trend: your data will be safe by default. If you want better performance you can always put your /usr directory in its own unencrypted partition, or only encrypt /home, /tmp and swap, but I don’t want people knowing what software I have installed anyway (why does he have john the ripper on there? he *must* be up to something!)

Finally, you asked for an example large files that have to be kept private: Right now I have about 45-50GB of videos and photos on my PC, most of which isn’t mine. I have permission to keep all of them for personal use, but if my laptop gets stolen and someone starts selling my associates content then I’ve failed to protect their commercial interests. Other examples: work-related database dumps or source code repositories, scientific data, the ever pervasive pr0n (including legally downloaded), the cache of your local http proxy, etc etc.

Sorry for the long post. I hope this gives you some idea of why we might want / encrypted

Cheers,

Darren