# dmcrypt + luks Benchmarks

## ddaas

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

----------

## Nuteater

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.

----------

## nielchiano

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

 

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.

----------

## Nuteater

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

 

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  :Wink: . 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  :Wink: .

----------

## nielchiano

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

----------

## Nuteater

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.

----------

## nielchiano

 *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

----------

## nielchiano

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

 

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:

```
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

----------

## blank_vlad

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

 

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.

----------

## nielchiano

 *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

----------

## blank_vlad

 *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".   :Laughing: 

----------

## nielchiano

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?

----------

