View previous topic :: View next topic |
Author |
Message |
creaker l33t
Joined: 14 Jul 2012 Posts: 651
|
Posted: Tue Sep 09, 2014 6:41 pm Post subject: Encrypted volume read/write too fast... |
|
|
Hi!
I encrypted one of the partitions following this wiki page: http://wiki.gentoo.org/wiki/Dm-crypt
Once got device mounted, I decided to test read/write performance. I copied a 4Gb file and paste it into container. Unexpectedly file was copied too fast: operation took 45 secs. It's a 91Mb/sec. Afaik, it shouldn't be so fast. The read/write speed for encrypted partition should be 20-70 Mb/sec according to this benchmark: http://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/
Encrypted partition status:
Code: | localhost ~ # cryptsetup status cv
/dev/mapper/cv is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/sdb2
offset: 4096 sectors
size: 447426560 sectors
mode: read/write |
It even faster than copy to plain (non-encrypted) partition.
Assuming something wrong with my setup. Either data encryption compromised or not encrypted at all.
Any thoughts? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Wed Sep 10, 2014 1:02 am Post subject: |
|
|
I think you are using a 5+ year old benchmark to analyze the performance of hardware you did not describe. If you have a much faster system, good hardware offload, or used more caching than was used in the benchmark, then comparing your results to theirs is meaningless. I see that the blog post was edited a year after its posting to note that DM-Crypt became SMP aware, which could affect performance. |
|
Back to top |
|
|
HeissFuss Guru
Joined: 11 Jan 2005 Posts: 414
|
Posted: Wed Sep 10, 2014 2:35 am Post subject: |
|
|
Are you measuring the time it takes to copy and sync to disk, or just copy? When the copy completes, that just means it's in RAM disk buffer, prior to encryption/disk write.
Also, AES with any modern Intel processes does AES-NI CPU offload of AES, which is very fast. You can benchmark the actual CPU throughput (minus disk) with 'cryptsetup benchmark' |
|
Back to top |
|
|
creaker l33t
Joined: 14 Jul 2012 Posts: 651
|
Posted: Wed Sep 10, 2014 2:57 am Post subject: |
|
|
@ Hu
I saw that the date is 2009. The HDD used for linked above benchmark even faster than mine: 105Mb/s vs 100Mb/s.
Though, you are right, multithreading might be enabled by default since 2009. I wasn't aware of it. |
|
Back to top |
|
|
creaker l33t
Joined: 14 Jul 2012 Posts: 651
|
Posted: Wed Sep 10, 2014 3:04 am Post subject: |
|
|
HeissFuss wrote: |
Also, AES with any modern Intel processes does AES-NI CPU offload of AES, which is very fast. You can benchmark the actual CPU throughput (minus disk) with 'cryptsetup benchmark' |
Code: | localhost ~ # cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 485451 iterations per second
PBKDF2-sha256 249660 iterations per second
PBKDF2-sha512 163227 iterations per second
PBKDF2-ripemd160 376643 iterations per second
PBKDF2-whirlpool 204161 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 151,2 MiB/s 208,3 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b N/A N/A
aes-cbc 256b 122,0 MiB/s 155,9 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b N/A N/A
aes-xts 256b 209,7 MiB/s 210,4 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b N/A N/A
aes-xts 512b 156,1 MiB/s 157,5 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b N/A N/A |
Yes, seems this benchmark proves that 91Mb/s is real transfer speed.
Thanks. |
|
Back to top |
|
|
|