[dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[shmick]

hello all,

any advice to overcome this?

i don't want to change ciphers or other crypto options

ive tried both --cipher twofish-xts-plain64 and --cipher aes-xts-plain64

prior i did modprobe relevant ciphers, hashes

appart for waiting for zero issues, i also cannot benchmark

please see below

running from an amd-64 linux mint 13 system 3 disk software raid 5





cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
--use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0
# cryptsetup 1.6.2 processing "cryptsetup --debug --hash sha512 --cipher
twofish-xts-plain64 --use-random --key-size 256 --iter-time 2000
luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt version 1.11.1, dm-ioctl version 4.22.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 2000 miliseconds.
# RNG set to 1 (random).
# Interactive passphrase entry requested.
Enter passphrase:
Verify passphrase:
# Formatting device /dev/md0 as type LUKS1.
# Initialising gcrypt crypto backend.
# Topology: IO (131072/262144), offset = 0; Required alignment is
1048576 bytes.
# Generating LUKS header version 1 using hash sha512, twofish,
xts-plain64, MK 32 bytes
# PBKDF2: 109673 iterations per second using hash sha512.
# Data offset 4096, UUID dcdd4e2c-c8c9-4c62-aaf7-e417506c5f44, digest
iterations 26750
# Updating LUKS header of size 1024 on device /dev/md0
# Reading LUKS header of size 1024 from device /dev/md0
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Key slot 0 use 107101 password iterations.
# Using hash sha512 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area on device /dev/md0.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-6322
# Udev cookie 0xd4dac4c (semid 294919) created
# Udev cookie 0xd4dac4c (semid 294919) incremented
# Udev cookie 0xd4dac4c (semid 294919) incremented
# Udev cookie 0xd4dac4c (semid 294919) assigned to dm_task type 0 with
flags 0xe
# dm create temporary-cryptsetup-6322
CRYPT-TEMP-temporary-cryptsetup-6322 OF   [16384]
# temporary-cryptsetup-6322: Stacking NODE_ADD (252,0) 0:6 0660
# dm reload temporary-cryptsetup-6322  OF   [16384]
# dm resume temporary-cryptsetup-6322  OF   [16384]
# temporary-cryptsetup-6322: Stacking NODE_READ_AHEAD 1024 (flags=1)
# Udev cookie 0xd4dac4c (semid 294919) decremented
# Udev cookie 0xd4dac4c (semid 294919): Waiting for zero


./configure --with-crypto_backend=openssl --enable-dev-random

cryptsetup benchmark

# Tests are approximate using memory only (no storage IO).
cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf,
version CRYPTSETUP_1.0 not defined in file libcryptsetup.so.4 with link
time reference

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[Milan Broz]

On 11/20/2013 05:44 PM, shmick@riseup.net wrote:
> ./configure --with-crypto_backend=openssl --enable-dev-random
> 
> cryptsetup benchmark
> 
> # Tests are approximate using memory only (no storage IO).
> cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf,
> version CRYPTSETUP_1.0 not defined in file libcryptsetup.so.4 with link
> time reference

You are compiling own version, but code apparently tries to load old
libryptsetup library from system.
(And it seems I did lib versioning wrong here ...)

Either try to run src/cryptsetup (libtool wrapper should provide proper paths)
or override library path using LD_LIBRARY_PATH.
(it should point to src/lib/.libs or so)

(Or if you installed compiled version, be sure it overwrites old libcryptsetup.)

Milan

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[shmick]

Milan Broz:
> 
> On 11/20/2013 05:44 PM, shmick@riseup.net wrote:
>> ./configure --with-crypto_backend=openssl --enable-dev-random
>>
>> cryptsetup benchmark
>>
>> # Tests are approximate using memory only (no storage IO).
>> cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf,
>> version CRYPTSETUP_1.0 not defined in file libcryptsetup.so.4 with link
>> time reference
> 
> You are compiling own version, but code apparently tries to load old
> libryptsetup library from system.
> (And it seems I did lib versioning wrong here ...)

i tried compiling with libgcrypt 1.5.3 but the same errors occur

> 
> Either try to run src/cryptsetup (libtool wrapper should provide proper paths)
> or override library path using LD_LIBRARY_PATH.
> (it should point to src/lib/.libs or so)

same problem
./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib
(this is where libgcrypt is)

> 
> (Or if you installed compiled version, be sure it overwrites old libcryptsetup.)

ive also then tried with my distro default cryptsetup 1.4.1 but the same
errors again in xts mode with AES or TWOFISH

any ideas ???

> 
> Milan
> 

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[Milan Broz]

On 11/21/2013 03:55 PM, shmick@riseup.net wrote:
> ive also then tried with my distro default cryptsetup 1.4.1 but the same
> errors again in xts mode with AES or TWOFISH
> 
> any ideas ???

Did you modified udev device-mapper rules? If not, perhaps you should report
it to your distro bugzilla if it doesn't work with default package.

(The "waiting to zero" is in fact libdevmapper internal problem, cryptsetup is
just an user here.)
Usually it is caused byt removal of mandatory device-mapper udev rules.

Cipher or dmcrypt configuration is perhaps not related to this.

Milan

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[shmick]

Milan Broz:
> On 11/21/2013 03:55 PM, shmick@riseup.net wrote:
>> ive also then tried with my distro default cryptsetup 1.4.1 but the same
>> errors again in xts mode with AES or TWOFISH
>>
>> any ideas ???
> 
> Did you modified udev device-mapper rules? If not, perhaps you should report
> it to your distro bugzilla if it doesn't work with default package.

no, i didn't modify udev
i've done some more testing and im very certain this an ascii character
issue with cryptsetup 1.4.3

i did test the following:

1.
will all the previous problems i was using 63 random ascii characters
i triple checked all of these according to the wikipedia 95 character
standards - they are all ok according to ascii tables

so i then tried with a basic password - it worked fine using identical
luksFormat setings when creating and opening cryptsetup 1.4.3 from a live cd

however, i could not later open this same volume within linux mint 13
amd-64 using cryptsetup 1.4.1 - same waiting for zero error

i don't know if different versions of mdadm affect this - i created RAID
using latest mdadm 3.3 - the live cd has an earlier version, but it
still opens and assembles the raid anyhow

2.
re-installed cryptsetup 1.6.2 in linux mint 13
./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib

reboot

create volume
cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
--use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0

try basic password with letters & numbers only

failed again, hung at 'waiting for zero'

same problem errors with failing to run benchmark

i don't understand how to get around this

desired outcomes:
i want to use a long, secure passphrase, formatting with
[twofish][aes]-xts-plain64 - to me it doesnt matter which cryptsetup
version i use as long as it works

but so far i can't use 63 ascii charaters in any of the versions ive tried

?

> 
> (The "waiting to zero" is in fact libdevmapper internal problem, cryptsetup is
> just an user here.)
> Usually it is caused byt removal of mandatory device-mapper udev rules.

what does this mean ?
how would i fix this for myself and what would i change regarding a udev
conf option ?

> 
> Cipher or dmcrypt configuration is perhaps not related to this.
> 
> Milan
> 

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[Milan Broz]

On 11/22/2013 08:40 AM, shmick@riseup.net wrote:
> 
> 
> Milan Broz:
>> On 11/21/2013 03:55 PM, shmick@riseup.net wrote:
>>> ive also then tried with my distro default cryptsetup 1.4.1 but the same
>>> errors again in xts mode with AES or TWOFISH
>>>
>>> any ideas ???
>>
>> Did you modified udev device-mapper rules? If not, perhaps you should report
>> it to your distro bugzilla if it doesn't work with default package.
> 
> no, i didn't modify udev
> i've done some more testing and im very certain this an ascii character
> issue with cryptsetup 1.4.3


No. Why ascii characters problem?

"Waiting for zero" is situation where device mapper wait for semaphore
(used to synchronize block device creation) to reach zero, it is handled in udev rules
by generic device-mapper rules.

It has absolutely nothing to do with passwords or ciphers in cryptsetup. I am afraid
you are mixing several problems together here.
(You should get "No key available with this passphrase" error and not hang if it is
passphrase problem.)

BTW if you just need to open old container, do not compile own version and use
distro provided one (1.4 version is fully compatible here).

Anyway, adding cc to Peter who maybe know some problem in dm udev rules causing
this...

And if you cannot run even benchmark, you are still loading wrong libcryptsetup library,
(cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf - this
function was added later, in cryptsetup 1.6).

Milan


> 
> i did test the following:
> 
> 1.
> will all the previous problems i was using 63 random ascii characters
> i triple checked all of these according to the wikipedia 95 character
> standards - they are all ok according to ascii tables
> 
> so i then tried with a basic password - it worked fine using identical
> luksFormat setings when creating and opening cryptsetup 1.4.3 from a live cd
> 
> however, i could not later open this same volume within linux mint 13
> amd-64 using cryptsetup 1.4.1 - same waiting for zero error
> 
> i don't know if different versions of mdadm affect this - i created RAID
> using latest mdadm 3.3 - the live cd has an earlier version, but it
> still opens and assembles the raid anyhow
> 
> 2.
> re-installed cryptsetup 1.6.2 in linux mint 13
> ./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib
> 
> reboot
> 
> create volume
> cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
> --use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0
> 
> try basic password with letters & numbers only
> 
> failed again, hung at 'waiting for zero'
> 
> same problem errors with failing to run benchmark
> 
> i don't understand how to get around this
> 
> desired outcomes:
> i want to use a long, secure passphrase, formatting with
> [twofish][aes]-xts-plain64 - to me it doesnt matter which cryptsetup
> version i use as long as it works
> 
> but so far i can't use 63 ascii charaters in any of the versions ive tried
> 
> ?
> 
>>
>> (The "waiting to zero" is in fact libdevmapper internal problem, cryptsetup is
>> just an user here.)
>> Usually it is caused byt removal of mandatory device-mapper udev rules.
> 
> what does this mean ?
> how would i fix this for myself and what would i change regarding a udev
> conf option ?
> 
>>
>> Cipher or dmcrypt configuration is perhaps not related to this.
>>
>> Milan
>>

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[shmick]

Milan Broz:
> On 11/22/2013 08:40 AM, shmick@riseup.net wrote:
>>
>>
>> Milan Broz:
>>> On 11/21/2013 03:55 PM, shmick@riseup.net wrote:
>>>> ive also then tried with my distro default cryptsetup 1.4.1 but the same
>>>> errors again in xts mode with AES or TWOFISH
>>>>
>>>> any ideas ???
>>>
>>> Did you modified udev device-mapper rules? If not, perhaps you should report
>>> it to your distro bugzilla if it doesn't work with default package.
>>
>> no, i didn't modify udev
>> i've done some more testing and im very certain this an ascii character
>> issue with cryptsetup 1.4.3
> 
> 
> No. Why ascii characters problem?
> 
> "Waiting for zero" is situation where device mapper wait for semaphore
> (used to synchronize block device creation) to reach zero, it is handled in udev rules
> by generic device-mapper rules.
> 
> It has absolutely nothing to do with passwords or ciphers in cryptsetup. I am afraid
> you are mixing several problems together here.
> (You should get "No key available with this passphrase" error and not hang if it is
> passphrase problem.)

why does luksFormat succeed using a simple short password and fail with
a more complex, longer one ?

this occurs in parted magic boot cd from 28-02-2013

> 
> BTW if you just need to open old container, do not compile own version and use
> distro provided one (1.4 version is fully compatible here).

i attempted to open with the distro provided 1.4.1 but it failed to open

> 
> Anyway, adding cc to Peter who maybe know some problem in dm udev rules causing
> this...
> 
> And if you cannot run even benchmark, you are still loading wrong libcryptsetup library,
> (cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf - this
> function was added later, in cryptsetup 1.6).

what else needs to be modified for configure options for this to work ?

> 
> Milan
> 
> 
>>
>> i did test the following:
>>
>> 1.
>> will all the previous problems i was using 63 random ascii characters
>> i triple checked all of these according to the wikipedia 95 character
>> standards - they are all ok according to ascii tables
>>
>> so i then tried with a basic password - it worked fine using identical
>> luksFormat setings when creating and opening cryptsetup 1.4.3 from a live cd
>>
>> however, i could not later open this same volume within linux mint 13
>> amd-64 using cryptsetup 1.4.1 - same waiting for zero error
>>
>> i don't know if different versions of mdadm affect this - i created RAID
>> using latest mdadm 3.3 - the live cd has an earlier version, but it
>> still opens and assembles the raid anyhow
>>
>> 2.
>> re-installed cryptsetup 1.6.2 in linux mint 13
>> ./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib
>>
>> reboot
>>
>> create volume
>> cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
>> --use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0
>>
>> try basic password with letters & numbers only
>>
>> failed again, hung at 'waiting for zero'
>>
>> same problem errors with failing to run benchmark
>>
>> i don't understand how to get around this
>>
>> desired outcomes:
>> i want to use a long, secure passphrase, formatting with
>> [twofish][aes]-xts-plain64 - to me it doesnt matter which cryptsetup
>> version i use as long as it works
>>
>> but so far i can't use 63 ascii charaters in any of the versions ive tried
>>
>> ?
>>
>>>
>>> (The "waiting to zero" is in fact libdevmapper internal problem, cryptsetup is
>>> just an user here.)
>>> Usually it is caused byt removal of mandatory device-mapper udev rules.
>>
>> what does this mean ?
>> how would i fix this for myself and what would i change regarding a udev
>> conf option ?
>>
>>>
>>> Cipher or dmcrypt configuration is perhaps not related to this.
>>>
>>> Milan
>>>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[Milan Broz]

On 11/22/2013 09:38 AM, shmick@riseup.net wrote:

> 
> why does luksFormat succeed using a simple short password and fail with
> a more complex, longer one ?
> 
> this occurs in parted magic boot cd from 28-02-2013

It seems that there is no free download. Sorry, cannot even try it. Ask them.

It works with upstream build, in fact, maximal interactive password length
can be seen in cryptsetup --help:
...
Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 1000 (ms)

Milan

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[shmick]

Milan Broz:
> On 11/22/2013 09:38 AM, shmick@riseup.net wrote:
> 
>>
>> why does luksFormat succeed using a simple short password and fail with
>> a more complex, longer one ?
>>
>> this occurs in parted magic boot cd from 28-02-2013
> 
> It seems that there is no free download. Sorry, cannot even try it. Ask them.

yes i believe the author of that went through some troubles a while back
- i was not aware you could not download any version anymore

> 
> It works with upstream build, in fact, maximal interactive password length
> can be seen in cryptsetup --help:

mind if i ask which distro you were able to successfully luksFormat to
in cryptsetup 1.6.2 issuing:

cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
--use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0

what were your compile switches ?

> ...
> Default compiled-in key and passphrase parameters:
>         Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
> Default PBKDF2 iteration time for LUKS: 1000 (ms)
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

[Milan Broz]

On 11/22/2013 12:56 PM, shmick@riseup.net wrote:
> 
> 
> Milan Broz:
>> On 11/22/2013 09:38 AM, shmick@riseup.net wrote:
>>
>>>
>>> why does luksFormat succeed using a simple short password and fail with
>>> a more complex, longer one ?
>>>
>>> this occurs in parted magic boot cd from 28-02-2013
>>
>> It seems that there is no free download. Sorry, cannot even try it. Ask them.
> 
> yes i believe the author of that went through some troubles a while back
> - i was not aware you could not download any version anymore
> 
>>
>> It works with upstream build, in fact, maximal interactive password length
>> can be seen in cryptsetup --help:
> 
> mind if i ask which distro you were able to successfully luksFormat to
> in cryptsetup 1.6.2 issuing:

Fedora, RHEL, CentOS, Debian, Gentoo, ...

If you run just configure without switches, you should get working output.
(Obviously you need all library dependences configured.)

Maybe you can try to compile it with --disable-udev but this can add way
of more problems than you already have.

But as I said, you do not need to compile it yourself, use distro version.

Sorry, this is not upstream issue, maybe someone on list using the same distro
can help better.

> cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
> --use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0

FYI this is how it should work (password is >100 chars),
this is on Fedora 19 with system installed cryptsetup (1.6.2) for example.

[root@localhost ~]# cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64 --use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0
# cryptsetup 1.6.2 processing "cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64 --use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend library.
# Timeout set to 0 miliseconds.
# Iteration time set to 2000 miliseconds.
# RNG set to 1 (random).
# Interactive passphrase entry requested.
Enter passphrase: 
Verify passphrase: 
# Checking new password using default pwquality settings.
# New password libpwquality score is 100.
# Formatting device /dev/md0 as type LUKS1.
# Crypto backend (gcrypt 1.5.3) initialized.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Generating LUKS header version 1 using hash sha512, twofish, xts-plain64, MK 32 bytes
# Crypto backend (gcrypt 1.5.3) initialized.
# KDF pbkdf2, hash sha512: 137248 iterations per second.
# Data offset 4096, UUID 412085a1-3abe-4f36-8826-7711c8ce6c28, digest iterations 33500
# Updating LUKS header of size 1024 on device /dev/md0
# Key length 32, device size 40832 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/md0
# Key length 32, device size 40832 sectors, header size 2050 sectors.
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Crypto backend (gcrypt 1.5.3) initialized.
# KDF pbkdf2, hash sha512: 131863 iterations per second.
# Key slot 0 use 128771 password iterations.
# Using hash sha512 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area.
# Calculated device size is 250 sectors (RW), offset 8.
# Detected kernel Linux 3.11.8-200.fc19.x86_64 x86_64.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.12.1, dm-ioctl version 4.25.0.
# Device-mapper backend running with UDEV support enabled.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-1216
# Udev cookie 0xd4d78b0 (semid 229376) created
# Udev cookie 0xd4d78b0 (semid 229376) incremented to 1
# Udev cookie 0xd4d78b0 (semid 229376) incremented to 2
# Udev cookie 0xd4d78b0 (semid 229376) assigned to CREATE task(0) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm create temporary-cryptsetup-1216 CRYPT-TEMP-temporary-cryptsetup-1216 OF   [16384] (*1)
# dm reload temporary-cryptsetup-1216  OFW    [16384] (*1)
# dm resume temporary-cryptsetup-1216  OFW    [16384] (*1)
# temporary-cryptsetup-1216: Stacking NODE_ADD (253,2) 0:6 0660 [verify_udev]
# temporary-cryptsetup-1216: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d78b0 (semid 229376) decremented to 1
# Udev cookie 0xd4d78b0 (semid 229376) waiting for zero
# Udev cookie 0xd4d78b0 (semid 229376) destroyed
# temporary-cryptsetup-1216: Processing NODE_ADD (253,2) 0:6 0660 [verify_udev]
# temporary-cryptsetup-1216: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-1216 (253:2): read ahead is 256
# temporary-cryptsetup-1216 (253:2): Setting read ahead to 256
# Udev cookie 0xd4de367 (semid 262144) created
# Udev cookie 0xd4de367 (semid 262144) incremented to 1
# Udev cookie 0xd4de367 (semid 262144) incremented to 2
# Udev cookie 0xd4de367 (semid 262144) assigned to REMOVE task(2) with flags (0x0)
# dm remove temporary-cryptsetup-1216  OFT    [16384] (*1)
# temporary-cryptsetup-1216: Stacking NODE_DEL [verify_udev]
# Udev cookie 0xd4de367 (semid 262144) decremented to 1
# Udev cookie 0xd4de367 (semid 262144) waiting for zero
# Udev cookie 0xd4de367 (semid 262144) destroyed
# temporary-cryptsetup-1216: Processing NODE_DEL [verify_udev]
# Key slot 0 was enabled in LUKS header.
# Updating LUKS header of size 1024 on device /dev/md0
# Key length 32, device size 40832 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/md0
# Key length 32, device size 40832 sectors, header size 2050 sectors.
# Releasing crypt device /dev/md0 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.

[root@localhost ~]# cryptsetup  luksOpen /dev/md0 test
Enter passphrase for /dev/md0: 

[root@localhost ~]# cryptsetup status test
/dev/mapper/test is active.
  type:    LUKS1
  cipher:  twofish-xts-plain64
  keysize: 256 bits
  device:  /dev/md0
  offset:  4096 sectors
  size:    36736 sectors
  mode:    read/write

Milan