cryptsetup 1.0.7 speed is slow, kernel version is 2.6.18-164.el5

[GoogleCodeExporter]

Hi, Sir
I am using cryptsetup 1.0.7 on CentOS 5.4. cryptsetup is too slow to do 
luksFormat and luksOpen. My CentOS 5.4 kernel version is 2.6.18-164.el5

Here is my steps:
1. dd if=/dev/zero of=temp.bin bs=1M count=1 seek=10
2. losetup /dev/loop7 temp.bin
3. /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 128 
/dev/loop7 rawkeyfile
4. /sbin/cryptsetup luksOpen /dev/loop7 liutest --key-file rawkeyfile

all commands return successful. But the step3 cost me 2 minutes and 35 seconds. 
The step4 cost me 45 seconds

And attach rawkeyfile

I also do the same testing by kernel 2.6.18-xenU-ec2-v1.4 , no speed issue.

So does cryptsetup 1.0.7 have any requirement for kernel version?
Can I get any help form you?
Thanks
liuliu

Original issue reported on code.google.com by 6liu...@gmail.com on 28 Sep 2010 at 9:27

Attachments:

• rawkeyfile

[GoogleCodeExporter]

There is no specific requirement for kernel version.

Did you compiled 1.0.7 yourself? CentOS have 1.0.3 in repository. Where did you 
get this version for CentOS 5? Which architecture? (x86_64/i686?)

# time /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 
128 /dev/loop7 rawkeyfile
Command successful.

real    0m1.708s
user    0m1.520s
sys     0m0.151s

# time /sbin/cryptsetup luksOpen /dev/loop7 liutest --key-file rawkeyfile
key slot 0 unlocked.
Command successful.

real    0m0.542s
user    0m0.516s
sys     0m0.010s

# rpm -q kernel cryptsetup-luks
kernel-2.6.18-194.11.4.el5
cryptsetup-luks-1.0.3-5.el5

Please can you provide "rpm -q cryptsetup-luks", luksDump /dev/loop7?

Can you try it run it on some physical device and not loop (e.g. USB stick) - 
is it slow too?

Can you try to add "-i 1" to luksFormat - will it hekp significantly?

(btw using -h ripemd160 is ignored in cryptsetup 1.0.x, do not use it with LUKS)

Also try to strace it and check where it waits. (1.0.7 have no debug switch, 
with 1.1.3 version you can run it with --debug)

If tyou are compiling cryptsetup yourself use 1.1.3 version (it will work on 
CentOS 5).

Original comment by gmazyl...@gmail.com on 28 Sep 2010 at 2:47

[GoogleCodeExporter]

Hi, Gmazyland
Thanks for your help.

My CentOS5.4 (i686) is a virtual machine, it run on VMware ESX 4.1
I install CentOS5.4 by DVD iso file. And it include cryptsetup 1.0.3 by default.
But I compiled cryptsetup 1.0.7 myself, and donot uninstall 1.0.3, I just 
replace 1.0.3 by 1.0.7

How I compile cryptsetup 1.0.7
1.  yum -y install gcc automake autoconf libtool make
2.  yum -y install e2fsprogs-devel
3.  wget http://cryptsetup.googlecode.com/files/cryptsetup-1.0.7.tar.bz2
4.  tar jxvf cryptsetup-1.0.7.tar.bz2
5.  cd cryptsetup-1.0.7
6.  ./configure
7.  make
8.  make install
9.  mv /sbin/cryptsetup /sbin/cryptsetup_bak
10. cp /usr/sbin/cryptsetup /sbin/cryptsetup

Here I list some my CentOS5.4 infomation
# uname -a
Linux PS-RC-1155 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 
i386 GNU/Linux

# rpm -q cryptsetup-luks
cryptsetup-luks-1.0.3-5.el5

# cryptsetup --version
cryptsetup 1.0.7

# /sbin/cryptsetup luksDump /dev/loop7
LUKS header information for /dev/loop7

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      61 89 1a 6a 7e 24 d4 4e 0f 60 db f0 4c f8 a7 03 58 8d c3 54
MK salt:        92 16 af fb 2e e3 c9 11 b1 d2 8c 87 02 68 4d 87
                e2 d5 f3 df 69 2a 58 e2 c3 df 83 8f da a8 a2 94
MK iterations:  10
UUID:           324b42eb-c209-489d-8834-4a1ded5f7709

Key Slot 0: ENABLED
        Iterations:             1747537
        Salt:                   65 9d 3f 26 1c 0b 50 61 2e 80 93 84 37 6e 93 79
                                62 98 d4 2b 1d c0 2b f8 81 ac b8 05 30 c7 0a 6e
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Testing to add "-i 1" to luksFormat
# /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 128 -i 
1 /dev/loop7 rawkeyfile
Command successful.

It still cost about 1.5 minutes

# /sbin/cryptsetup luksDump /dev/loop7
LUKS header information for /dev/loop7

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      d1 ec 8b 8f fb c2 26 d8 0a a5 8d c1 7b e2 82 a0 58 95 f8 75
MK salt:        ef fd ca 8d 1c f9 d1 75 b0 14 78 cc da f9 19 c1
                85 80 4e 4f cf 1b b1 01 44 ce 40 84 21 4f da 06
MK iterations:  10
UUID:           aafd1bf3-00ef-41ff-b715-d6346e92da7d

Key Slot 0: ENABLED
        Iterations:             1745
        Salt:                   f6 ef 8b c1 18 3c 7f 41 38 ac a3 86 10 ab 4b d2
                                c8 93 27 6c 1d f7 ec 44 ed 94 a2 8a 98 a2 80 58
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Testing to cryptsetup 1.1.3
I compile cryptsetup 1.1.3, it needs libgcrypt version higher than 1.4.4, so I 
also compile libgcrypt-1.4.6 to support cryptsetup 1.1.3

/sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 128 
/dev/loop7 rawkeyfile
'luksFormat' cost me about 18 seconds, Does 18 seconds reasonable for 10MB file 
size?

/sbin/cryptsetup luksOpen /dev/loop7 liutest --key-file rawkeyfile
'luksOpen' cost me about 2 seconds.

And attach debuglog and luksDump for 1.1.3
# /sbin/cryptsetup luksFormat --debug  -q -c aes-cbc-essiv:sha256 -h ripemd160 
-s 128 /dev/loop7 awkeyfile
# cryptsetup 1.1.3 processing "/sbin/cryptsetup luksFormat --debug -q -c 
aes-cbc-essiv:sha256 -h ripemd160 -s 128 /dev/loop7 rawkeyfile"
# Locking memory.
# Allocating crypt device /dev/loop7 context.
# Trying to open and read device /dev/loop7.
# Initialising device-mapper backend, UDEV is disabled.
# Detected dm-crypt target of version 1.3.0.
# Timeout set to 0 miliseconds.
# Password retry count set to 0.
# Iteration time set to 1000 miliseconds.
# Password verification disabled.
# Formatting device /dev/loop7 as type LUKS1.
# Initializing crypto backend (using secure memory).
# Topology info for /dev/loop7 not supported, using default offset 4096 bytes.
# Generating LUKS header version 1 using hash ripemd160, aes, cbc-essiv:sha256, 
MK 16 bytes
# PBKDF2: 198027 iterations per second using hash ripemd160.
# Data offset 1032, UUID 615b8207-423c-4d75-9ba6-d643a7bcc4a8, digest 
iterations 24125
# Updating LUKS header of size 1024 on device /dev/loop7
# Reading LUKS header of size 1024 from device /dev/loop7
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Key slot 0 use 96692 password iterations.
# Using hash ripemd160 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area on device /dev/loop7.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-3691
# dm create temporary-cryptsetup-3691 CRYPT-TEMP-temporary-cryptsetup-3691 OF   
[16384]
# temporary-cryptsetup-3691: Stacking NODE_ADD (253,3) 0:6 0660
# dm reload temporary-cryptsetup-3691  OF   [16384]
# dm resume temporary-cryptsetup-3691  OF   [16384]
# temporary-cryptsetup-3691: Stacking NODE_READ_AHEAD 256 (flags=1)
# Created /dev/mapper/temporary-cryptsetup-3691
# temporary-cryptsetup-3691: read ahead is 256
# temporary-cryptsetup-3691: Setting read ahead to 256
# dm remove temporary-cryptsetup-3691  OF   [16384]
# temporary-cryptsetup-3691: Stacking NODE_DEL (replaces other stacked ops)
# Removed /dev/mapper/temporary-cryptsetup-3691
# Key slot 0 was enabled in LUKS header.
# Updating LUKS header of size 1024 on device /dev/loop7
# Reading LUKS header of size 1024 from device /dev/loop7
# Releasing crypt device /dev/loop7 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.

# /sbin/cryptsetup luksDump /dev/loop7
LUKS header information for /dev/loop7

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      ripemd160
Payload offset: 1032
MK bits:        128
MK digest:      43 43 e4 49 e3 45 a9 58 d9 f5 a7 73 34 25 d3 49 f1 f9 1d bd
MK salt:        db 6d 4b 63 5e 50 75 53 d5 c8 5f 54 88 9f 7c cc
                57 ad e7 bd 29 10 f0 4a 7c db 05 4d 9c fb d4 29
MK iterations:  24125
UUID:           615b8207-423c-4d75-9ba6-d643a7bcc4a8

Key Slot 0: ENABLED
        Iterations:             96692
        Salt:                   4d cb 4a 9e 09 41 24 31 62 da 1b 98 e0 3f b1 cd
                                9a 89 c7 78 bb 19 54 71 33 42 56 5e eb 90 d0 6b
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Thanks for you reading the long mail:)
liuliu

Original comment by 6liu...@gmail.com on 29 Sep 2010 at 7:31

[GoogleCodeExporter]

ok, if you want compile it yourself, please use 1.1.x.

I can fully support only official build (1.0.3 from repository) or new upstream 
- not 1.0.7.

1.1.x should be compilable on RHEL/CentOS 5.5 and work  without any additional 
updates - if not, it is bug. Please let me know what do you need update.

So 1.1.x seems to calculate reasobable iterations count.

/sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 128 
/dev/loop7 rawkeyfile
'luksFormat' cost me about 18 seconds, Does 18 seconds reasonable for 10MB file 
size?

Can you try this on non-loop device? and run it with debug and tell me where it 
waits (on debuglog line)?

(there will be 1 second iteration check, so the wjhole formatting should that 
~2 seconds, it is not dependent of device size - it doesn't wipe whole device, 
just formats header.)

Original comment by gmazyl...@gmail.com on 29 Sep 2010 at 8:21

[GoogleCodeExporter]

I use 1.0.7, because I met speed issue on 1.0.3. I was think, 1.0.7 can fix my 
problem, but it seems I was get more problems:)

ok, since you can fully support 1.0.3, so I'd like tell you my testing result 
on 1.0.3.

1. my CentOS kernel is 2.6.18-164.el5
# uname -a
Linux CentOS5.4-3-001 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 
i686 i386 GNU/Linux

I try 'luksFormat' 2 times, they all all cost my 3+ minuts

# time /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 
128 /dev/loop7 rawkeyfile
Command successful.

real    3m53.715s
user    0m1.500s
sys     0m0.004s

# /sbin/cryptsetup luksDump /dev/loop7
LUKS header information for /dev/loop7

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      72 7f 90 9e 8f 7f 9b 66 2b 91 c5 21 97 e4 d8 2f 3d 50 c8 e3
MK salt:        6c 01 22 a1 1c a9 37 83 2b 00 b4 51 9a 99 e9 5a
                80 72 1d 5e 8e 86 17 c1 b1 3f 67 d0 b1 fe 1e d3
MK iterations:  10
UUID:           7a1682d6-751e-458f-81af-e70b72abd41c

Key Slot 0: ENABLED
        Iterations:             2494535
        Salt:                   9d 9c db cf 84 e2 16 c6 cf bf 90 2a 96 e3 41 ed
                                2e 00 d8 00 06 a9 b0 9b 06 30 99 64 f5 03 15 1e
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I am have not available non-loop device to test right now, I will update it 
later when I have.

Thanks
liuliu

Original comment by 6liu...@gmail.com on 29 Sep 2010 at 9:59

[GoogleCodeExporter]

update a news. 

It seems that 'luksFormat' speed become high, after I only update kernel.

# uname -a
Linux CentOS5.4-3-001 2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 05:09:20 EDT 2010 
i686 i686 i386 GNU/Linux

# time /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 
128 /dev/loop7 rawkeyfile
Command successful.

real    0m16.106s
user    0m1.509s
sys     0m0.057s

So, form my testing, kernel 2.6.18-194.11.4.el5 make cryptsetup 1.0.3 faster 
than 2.6.18-164.el5. Does those means, different kernel have different impact 
to cryptsetup 1.0.3 ?

Thanks
liuliu

Original comment by 6liu...@gmail.com on 29 Sep 2010 at 10:18

[GoogleCodeExporter]

My guess is the problem is in loop code not in crypt - that's why I want to 
check it for non-loop device.

16 seconds is too much anyway it should be ~2 seconds.

If you can reproduce it with updated  CentOS distro packages, please report it 
to Red Hat bugzilla (for RHEL cryptsetup)- if it is reproducible problem, it 
should be fixed.
(It will be assigned to me there anyway - if there are problems with old 
cryptsetup I'll try to request rebase or backport some changes.)

Original comment by gmazyl...@gmail.com on 29 Sep 2010 at 10:32

[GoogleCodeExporter]

update testing for non-loop device.

I add 128MB virtual disk (/dev/sdb), kernel is 2.6.18-194.11.4.el5. 
'luksFormat' cost about 16 minutes. The non-loop device test result is similar 
with loop device. 

# time /sbin/cryptsetup luksFormat -q -c aes-cbc-essiv:sha256 -h ripemd160 -s 
128 /dev/sdb rawkeyfile
Command successful.

real    0m16.992s
user    0m1.518s
sys     0m0.056s

# fdisk -l

Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        1044     8281507+  8e  Linux LVM

Disk /dev/sdb: 134 MB, 134217728 bytes
64 heads, 32 sectors/track, 128 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Disk /dev/sdb doesn't contain a valid partition table

Thanks
liuliu

Original comment by 6liu...@gmail.com on 30 Sep 2010 at 1:37

[GoogleCodeExporter]

Sorry, non-loop device cost 16 seconds, not 16 minutes. My typing error.

Original comment by 6liu...@gmail.com on 30 Sep 2010 at 1:48

[GoogleCodeExporter]

I was not able to reproduce it, as said, if you can reproduce it with recent 
kernel, please report it to Red Hat bugzilla.

Original comment by gmazyl...@gmail.com on 29 Oct 2010 at 8:29

• Changed state: Invalid