| View previous topic :: View next topic |
| Author |
Message |
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
 Posted: Wed May 24, 2006 1:06 pm Post subject: dmcrypt + luks Benchmarks |
 |
|
I am planning to encrypt my home directory on my laptop using dmcrypt+luks.
I am interesting in performance degradation comparing to an unencrypted file system.
Does anyone have some benchmark data? Are there any test results available?
On my windows system I am using truecrypt (www.truecrypt.org) and with some syntactical benchmarks I noted around 25-30 performance degradation (hdd read/write).
I have also a second question: is it necessary from a security point of view to encrypt the swap partition? why?
Thanks
_________________
Best regards,
ddaas |
|
| Back to top |
|
 |
Nuteater
Apprentice
Joined: 25 Sep 2003
Posts: 193
Location: Jyväskylä, Finland
|
| Posted: Wed May 24, 2006 11:42 pm Post subject: |
|
|
You can get the best benchmarks by encrypting a test partition yourself and using normal hard disk
benchmarking tools on your hardware, your algorithms and your enviroment. Most likely /home does
not get enough I/O-intensive traffic to give a major slowdown usage-wise -- modern CPUs decrypt and
encrypt data quite quickly.
Encrypting swap should be your starting point: no disk encryption is worth two bits if the decryption keys,
passwords and your secret love letters are swapped in clear to a swap partition. Also, encrypted swap is
easily done with /etc/conf.d/cryptfs, and unless you are really short of RAM, it will give you nearly zero
performance degradation as swap is rarely used. If you want to see what you have in plaintext on your
swap partition, try running strings on it.
_________________
I am Nuteater, hear me roar. |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Thu May 25, 2006 12:56 pm Post subject: |
|
|
| Nuteater wrote: | Encrypting swap should be your starting point: no disk encryption is worth two bits if the decryption keys,
passwords and your secret love letters are swapped in clear to a swap partition. Also, encrypted swap is
easily done with /etc/conf.d/cryptfs, and unless you are really short of RAM, it will give you nearly zero
performance degradation as swap is rarely used. If you want to see what you have in plaintext on your
swap partition, try running strings on it. |
I haven't checked this in this kind of setup, but there might be a security risk in this:
Every time you boot, a random key is generated to encrypt the swap. However, that random-generation is done using /dev/urandom and before the random seed is read from disk.
So it's possible that the "random key" is always the same, predictable, value, defeating the whole purpose.
On my setup I checked this, and this doesn't happen; but I have an encrypted root filesystem, so I have to manualy supply the password in the initrd, providing a source of some random data.
If you realy want to know, let me know... I'll make a test-setup for it. |
|
| Back to top |
|
|
Nuteater
Apprentice
Joined: 25 Sep 2003
Posts: 193
Location: Jyväskylä, Finland
|
| Posted: Thu May 25, 2006 1:52 pm Post subject: |
|
|
| nielchiano wrote: | I haven't checked this in this kind of setup, but there might be a security risk in this:
Every time you boot, a random key is generated to encrypt the swap. However, that random-generation is done using /dev/urandom and before the random seed is read from disk.
So it's possible that the "random key" is always the same, predictable, value, defeating the whole purpose.
On my setup I checked this, and this doesn't happen; but I have an encrypted root filesystem, so I have to manualy supply the password in the initrd, providing a source of some random data.
If you realy want to know, let me know... I'll make a test-setup for it. |
If this is the case, this is a serious issue indeed. The boot-order should make sure that the random seed is loaded
before doing anything remotely related to cryptography. I'll have to look into it. Of course we can just simply create
the key from /dev/random ...if there is enough entropy available at startup. Sometimes I just wish I had a hardware
RNG  . Another solution could be delaying activating the swap until there is enough entropy in /dev/random to
create the key.
Well, in any case, encrypting swap is a really good idea - at least when implemented properly .
_________________
I am Nuteater, hear me roar. |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Thu May 25, 2006 1:56 pm Post subject: |
|
|
| Nuteater wrote: | Of course we can just simply create
the key from /dev/random ...if there is enough entropy available at startup. |
I actualy tried this a long time ago, to do it from within the initrd. It literaly took forever (I gave up after 10 minutes and started to hit the keyboard) to get enough entropy on the headless server I tested it on... |
|
| Back to top |
|
|
Nuteater
Apprentice
Joined: 25 Sep 2003
Posts: 193
Location: Jyväskylä, Finland
|
| Posted: Fri May 26, 2006 3:18 pm Post subject: |
|
|
Urgh... It does indeed seem that the key to encrypt swap is generated before
/dev/urandom is initialized. Maybe nielchiano you could write a bug report on
this on gentoo's bugzilla? We are getting a bit off-topic here afterall.
_________________
I am Nuteater, hear me roar. |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Fri May 26, 2006 3:25 pm Post subject: |
|
|
| Nuteater wrote: | Urgh... It does indeed seem that the key to encrypt swap is generated before
/dev/urandom is initialized. Maybe nielchiano you could write a bug report on
this on gentoo's bugzilla? We are getting a bit off-topic here afterall. |
ok, I will: bug 134489 |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sat May 27, 2006 10:28 am Post subject: |
|
|
| Nuteater wrote: | You can get the best benchmarks by encrypting a test partition yourself and using normal hard disk
benchmarking tools on your hardware, your algorithms and your enviroment. Most likely /home does
not get enough I/O-intensive traffic to give a major slowdown usage-wise -- modern CPUs decrypt and
encrypt data quite quickly. |
Back to topic:
I did a benchmark to decide which cipher to use.
It should be noted that this is a synthetical test! And that you should always use cbc-essiv as mode!
All ciphers where given the same file to derive their key from, so that shouldn't matter much
Here are my results: | Code: | Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
128bit aes-cbc-plain 7 4096 1 283.98 97.36% 0.013 0.07 0.00000 0.00000 292
192bit aes-cbc-plain 7 4096 1 286.53 98.23% 0.013 0.07 0.00000 0.00000 292
256bit aes-cbc-plain 7 4096 1 278.44 95.46% 0.013 0.21 0.00000 0.00000 292
32bit blowfish-cbc-plain 7 4096 1 263.75 90.42% 0.014 2.23 0.00000 0.00000 292
128bit blowfish-cbc-plain 7 4096 1 284.09 97.40% 0.013 0.07 0.00000 0.00000 292
192bit blowfish-cbc-plain 7 4096 1 285.83 97.99% 0.013 0.07 0.00000 0.00000 292
256bit blowfish-cbc-plain 7 4096 1 280.67 96.23% 0.013 0.07 0.00000 0.00000 292
448bit blowfish-cbc-plain 7 4096 1 285.13 97.75% 0.013 0.07 0.00000 0.00000 292
128bit twofish-cbc-plain 7 4096 1 281.69 96.57% 0.013 0.07 0.00000 0.00000 292
192bit twofish-cbc-plain 7 4096 1 291.06 99.79% 0.012 0.08 0.00000 0.00000 292
256bit twofish-cbc-plain 7 4096 1 286.65 98.28% 0.013 0.08 0.00000 0.00000 292
64bit des-cbc-plain 7 4096 1 288.90 99.05% 0.013 0.08 0.00000 0.00000 292
192bit des3_ede-cbc-plain 7 4096 1 285.13 97.75% 0.013 0.08 0.00000 0.00000 292
256bit serpent-cbc-plain 7 4096 1 287.36 98.52% 0.013 0.08 0.00000 0.00000 292
256bit tnepres-cbc-plain 7 4096 1 287.00 98.40% 0.013 0.17 0.00000 0.00000 292
128bit cast5-cbc-plain 7 4096 1 288.78 99.00% 0.013 0.07 0.00000 0.00000 292
128bit cast6-cbc-plain 7 4096 1 281.58 96.54% 0.013 0.08 0.00000 0.00000 292
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
128bit aes-cbc-plain 7 4096 1 270.94 97.10% 0.012 0.05 0.00000 0.00000 279
192bit aes-cbc-plain 7 4096 1 272.64 97.71% 0.012 0.05 0.00000 0.00000 279
256bit aes-cbc-plain 7 4096 1 268.06 96.07% 0.012 0.04 0.00000 0.00000 279
32bit blowfish-cbc-plain 7 4096 1 252.26 90.41% 0.013 2.46 0.00000 0.00000 279
128bit blowfish-cbc-plain 7 4096 1 267.23 95.77% 0.012 0.05 0.00000 0.00000 279
192bit blowfish-cbc-plain 7 4096 1 271.08 97.15% 0.012 0.04 0.00000 0.00000 279
256bit blowfish-cbc-plain 7 4096 1 264.65 94.85% 0.012 0.05 0.00000 0.00000 279
448bit blowfish-cbc-plain 7 4096 1 269.68 96.65% 0.012 0.04 0.00000 0.00000 279
128bit twofish-cbc-plain 7 4096 1 266.46 95.49% 0.012 0.04 0.00000 0.00000 279
192bit twofish-cbc-plain 7 4096 1 271.36 97.25% 0.012 0.07 0.00000 0.00000 279
256bit twofish-cbc-plain 7 4096 1 270.24 96.85% 0.012 0.27 0.00000 0.00000 279
64bit des-cbc-plain 7 4096 1 275.33 98.67% 0.012 0.04 0.00000 0.00000 279
192bit des3_ede-cbc-plain 7 4096 1 269.72 96.66% 0.012 0.05 0.00000 0.00000 279
256bit serpent-cbc-plain 7 4096 1 271.98 97.47% 0.012 0.04 0.00000 0.00000 279
256bit tnepres-cbc-plain 7 4096 1 271.98 97.47% 0.012 0.05 0.00000 0.00000 279
128bit cast5-cbc-plain 7 4096 1 271.17 97.18% 0.012 0.04 0.00000 0.00000 279
128bit cast6-cbc-plain 7 4096 1 270.42 96.91% 0.012 0.04 0.00000 0.00000 279
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
128bit aes-cbc-plain 7 4096 1 13.64 98.98% 0.044 0.17 0.00000 0.00000 14
192bit aes-cbc-plain 7 4096 1 12.45 99.63% 0.043 0.18 0.00000 0.00000 12
256bit aes-cbc-plain 7 4096 1 11.47 99.63% 0.043 0.19 0.00000 0.00000 12
32bit blowfish-cbc-plain 7 4096 1 9.58 99.11% 0.043 0.19 0.00000 0.00000 10
128bit blowfish-cbc-plain 7 4096 1 9.60 99.88% 0.044 1.55 0.00000 0.00000 10
192bit blowfish-cbc-plain 7 4096 1 9.68 99.56% 0.043 0.20 0.00000 0.00000 10
256bit blowfish-cbc-plain 7 4096 1 9.52 99.60% 0.043 0.20 0.00000 0.00000 10
448bit blowfish-cbc-plain 7 4096 1 9.70 99.75% 0.043 0.19 0.00000 0.00000 10
128bit twofish-cbc-plain 7 4096 1 9.99 99.88% 0.044 0.23 0.00000 0.00000 10
192bit twofish-cbc-plain 7 4096 1 10.26 99.71% 0.044 0.19 0.00000 0.00000 10
256bit twofish-cbc-plain 7 4096 1 10.04 99.87% 0.043 0.19 0.00000 0.00000 10
64bit des-cbc-plain 7 4096 1 6.84 99.21% 0.045 3.53 0.00000 0.00000 7
192bit des3_ede-cbc-plain 7 4096 1 3.03 99.98% 0.043 0.41 0.00000 0.00000 3
256bit serpent-cbc-plain 7 4096 1 4.42 99.19% 0.044 1.31 0.00000 0.00000 4
256bit tnepres-cbc-plain 7 4096 1 4.37 99.83% 0.044 0.23 0.00000 0.00000 4
128bit cast5-cbc-plain 7 4096 1 8.28 99.84% 0.044 0.22 0.00000 0.00000 8
128bit cast6-cbc-plain 7 4096 1 5.05 99.30% 0.044 0.83 0.00000 0.00000 5
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
128bit aes-cbc-plain 7 4096 1 32.59 99.30% 0.023 0.07 0.00000 0.00000 33
192bit aes-cbc-plain 7 4096 1 29.25 99.59% 0.023 0.07 0.00000 0.00000 29
256bit aes-cbc-plain 7 4096 1 27.41 99.63% 0.023 0.07 0.00000 0.00000 28
32bit blowfish-cbc-plain 7 4096 1 16.88 73.01% 0.023 0.08 0.00000 0.00000 23
128bit blowfish-cbc-plain 7 4096 1 22.37 90.49% 0.024 1.51 0.00000 0.00000 25
192bit blowfish-cbc-plain 7 4096 1 23.10 99.93% 0.023 0.08 0.00000 0.00000 23
256bit blowfish-cbc-plain 7 4096 1 22.74 99.54% 0.023 1.66 0.00000 0.00000 23
448bit blowfish-cbc-plain 7 4096 1 23.03 99.65% 0.023 0.07 0.00000 0.00000 23
128bit twofish-cbc-plain 7 4096 1 23.87 99.61% 0.023 0.20 0.00000 0.00000 24
192bit twofish-cbc-plain 7 4096 1 23.85 99.51% 0.023 0.07 0.00000 0.00000 24
256bit twofish-cbc-plain 7 4096 1 23.78 98.64% 0.024 3.96 0.00000 0.00000 24
64bit des-cbc-plain 7 4096 1 16.85 99.65% 0.023 0.08 0.00000 0.00000 17
192bit des3_ede-cbc-plain 7 4096 1 7.54 99.95% 0.023 0.07 0.00000 0.00000 8
256bit serpent-cbc-plain 7 4096 1 10.84 99.89% 0.023 0.07 0.00000 0.00000 11
256bit tnepres-cbc-plain 7 4096 1 8.84 80.78% 0.023 0.08 0.00000 0.00000 11
128bit cast5-cbc-plain 7 4096 1 20.02 99.43% 0.023 0.07 0.00000 0.00000 20
128bit cast6-cbc-plain 7 4096 1 12.47 99.96% 0.023 0.07 0.00000 0.00000 12
|
The bench is written in Perl and uses tiotest as backend. Source can be posted if wanted |
|
| Back to top |
|
|
blank_vlad
n00b
Joined: 30 Jan 2005
Posts: 24
|
| Posted: Sat May 27, 2006 11:00 am Post subject: |
|
|
| nielchiano wrote: | | Nuteater wrote: | Urgh... It does indeed seem that the key to encrypt swap is generated before
/dev/urandom is initialized. Maybe nielchiano you could write a bug report on
this on gentoo's bugzilla? We are getting a bit off-topic here afterall. |
ok, I will: bug 134489 |
Where did you get the link to that "Disk cryptography with dm-crypt" doc? That doc is seriously out of date and shouldn't be used, and shouldn't be linked to from anywhere else on the Gentoo site. |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sat May 27, 2006 11:02 am Post subject: |
|
|
| blank_vlad wrote: | | Where did you get the link to that "Disk cryptography with dm-crypt" doc? That doc is seriously out of date and shouldn't be used, and shouldn't be linked to from anywhere else on the Gentoo site. |
Google? "gentoo crypt-swap", first hit |
|
| Back to top |
|
|
blank_vlad
n00b
Joined: 30 Jan 2005
Posts: 24
|
| Posted: Sat May 27, 2006 11:32 am Post subject: |
|
|
| nielchiano wrote: | | blank_vlad wrote: | | Where did you get the link to that "Disk cryptography with dm-crypt" doc? That doc is seriously out of date and shouldn't be used, and shouldn't be linked to from anywhere else on the Gentoo site. |
Google? "gentoo crypt-swap", first hit |
Google isn't always a good thing, it doesn't tell you what's crap and what's not. Nevertheless, you should have immediately been tipped off about the unofficial status of that doc by the name of chapter 2, "Prequisites".  |
|
| Back to top |
|
|
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sat May 27, 2006 11:36 am Post subject: |
|
|
ok, going WAY off topic, sorry
| blank_vlad wrote: | | nielchiano wrote: | | blank_vlad wrote: | | Where did you get the link to that "Disk cryptography with dm-crypt" doc? That doc is seriously out of date and shouldn't be used, and shouldn't be linked to from anywhere else on the Gentoo site. |
Google? "gentoo crypt-swap", first hit |
Google isn't always a good thing, it doesn't tell you what's crap and what's not. Nevertheless, you should have immediately been tipped off about the unofficial status of that doc by the name of chapter 2, "Prequisites". |
I agree on that. However, since the dm-crypt scritps are in baselayout, I consider the support for it official. Any document that tells me how to use that official feature will do for me. What URL should I use instead? |
|
| Back to top |
|
|
|
Networking & Security
