All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] luks container created on a system won't luksOpen on another
@ 2015-09-10 13:47 andrea rota
  2015-09-10 14:14 ` Milan Broz
  0 siblings, 1 reply; 3+ messages in thread
From: andrea rota @ 2015-09-10 13:47 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 6895 bytes --]

hi,

i recently created a new LUKS container via cryptsetup luksFormat on a
workstation and migrated some data to it; when connecting the same HDD
(eSATA) to a different box (a CuBox-i2eX) i am unable to luksOpen the
container. i checked the dm-crypt FAQ and i must be missing something
obvious as all the checks suggested there seem fine.

i tried also adding - on the source box - a second passphrase as simple
as four digits to a second LUKS slot (it's a test anyways so passphrase
strenght doesn't matter) - to avoid encoding/keyboard issues (though i also
tried copying and pasting the passphrase in a ssh shell), and when trying to
luksOpen the container on the CuBox i am still unable to do so.

to set up the container, i simply used `cryptsetup luksFormat /dev/sdxX`, hence
with the cryptsetup default parameters as listed below (these seem to be the
same on the two systems).

all details of both systems are listed below - they seem to match up (except
the fact that the target system has a longer list of hashes/ciphers compiled in
the kernel), so i'm likely missing something very obvious...

best
andrea

## source box (where i did the luksFormat and on which i can luksOpen the
container):

* kernel 3.19.0-26
* cryptsetup version 1.6.1 (Ubuntu 15.04)
* cryptsetup defaults:

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)

Default compiled-in device cipher parameters:
  loop-AES: aes, Key 256 bits
  plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
  LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom

* crypto hashes/ciphers (from /proc/crypto):

name         : cbc(aes)
name         : cbc(aes)
name         : hmac(sha256)
name         : hmac(sha1)
name         : skein1024
name         : skein512
name         : skein256
name         : stdrng
name         : lzo
name         : crct10dif
name         : crc32c
name         : aes
name         : sha384
name         : sha512
name         : sha224
name         : sha256
name         : sha1
name         : md5


## destination box (where i am unable to luksOpen the container):

* kernel 3.14.14
* cryptsetup version 1.6.6 (Debian Jessie)
* cryptsetup defaults:

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)

Default compiled-in device cipher parameters:
  loop-AES: aes, Key 256 bits
  plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
  LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom

* crypto hashes/ciphers:

name         : __xts-aes-neonbs
name         : xts(aes)
name         : ghash
name         : stdrng
name         : lzo
name         : crct10dif
name         : crc32c
name         : michael_mic
name         : camellia
name         : aes
name         : twofish
name         : blowfish
name         : des3_ede
name         : des
name         : tgr128
name         : tgr160
name         : tgr192
name         : wp256
name         : wp384
name         : wp512
name         : sha384
name         : sha512
name         : sha224
name         : sha256
name         : sha1
name         : rmd320
name         : rmd256
name         : rmd160
name         : rmd128
name         : md5
name         : md4
name         : digest_null
name         : compress_null
name         : ecb(cipher_null)
name         : cipher_null
name         : xts(aes)
name         : ctr(aes)
name         : cbc(aes)
name         : __xts-aes-neonbs
name         : __ctr-aes-neonbs
name         : __cbc-aes-neonbs
name         : aes

* on both systems i can read the LUKS header:

$ sudo cryptsetup luksDump /dev/sda1 
LUKS header information for /dev/sda1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      a3 c7 66 c4 a1 fb 0e 9e 51 49 90 ea c3 b6 03 9c 96 d9 3e 5e 
MK salt:        16 6e ef 91 d5 4a 5f 97 99 2b 85 b8 34 1f df 60 
                45 11 b0 33 a7 0a 29 48 a7 ab b7 74 f9 9a f6 20 
MK iterations:  39375
UUID:           b99c4fff-5e97-4de3-888d-1483c4098218

Key Slot 0: ENABLED
  Iterations:           159203
  Salt:                 90 46 2b 74 b6 cb b9 da 7d 31 24 06 c7 ad f2 31 
                          31 c4 85 9f 3c c3 ae 8d 9d 7c 6c eb 11 0c 30 0c 
  Key material offset:  8
  AF stripes:             4000
Key Slot 1: ENABLED
  Iterations:           306219
  Salt:                 31 f9 92 6a 47 47 64 fa 2e 90 39 9c 23 0a 1c 32 
                          56 9c 66 06 a2 18 00 1a 09 41 a2 3a 29 02 a3 ba 
  Key material offset:  264
  AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

* and finally, the output of luksOpen on the target system:

$ sudo cryptsetup luksOpen --verbose --debug /dev/sda1 test00
# cryptsetup 1.6.6 processing "cryptsetup luksOpen --verbose --debug /dev/sda1 test00"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/sda1 context.
# Trying to open and read device /dev/sda1.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/sda1.
# Crypto backend (gcrypt 1.6.3) initialized.
# Detected kernel Linux 3.14.14-cubox armv7l.
# Reading LUKS header of size 1024 from device /dev/sda1
# Key length 32, device size 5860530176 sectors, header size 2050 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume test00 [keyslot -1] using [none] passphrase.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Device-mapper backend running with UDEV support enabled.
# dm status test00  OF   [16384] (*1)
# Interactive passphrase entry requested.
Enter passphrase for /dev/sda1: 
# Trying to open key slot 0 [ACTIVE].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Trying to open key slot 1 [ACTIVE].
# Reading key slot 1 area.
# Using userspace crypto wrapper to access keyslot area.
# Trying to open key slot 2 [INACTIVE].
# Trying to open key slot 3 [INACTIVE].
# Trying to open key slot 4 [INACTIVE].
# Trying to open key slot 5 [INACTIVE].
# Trying to open key slot 6 [INACTIVE].
# Trying to open key slot 7 [INACTIVE].
No key available with this passphrase.
# Interactive passphrase entry requested.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1513 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dm-crypt] luks container created on a system won't luksOpen on another
  2015-09-10 13:47 [dm-crypt] luks container created on a system won't luksOpen on another andrea rota
@ 2015-09-10 14:14 ` Milan Broz
  2015-09-10 15:19   ` andrea rota
  0 siblings, 1 reply; 3+ messages in thread
From: Milan Broz @ 2015-09-10 14:14 UTC (permalink / raw)
  To: a, dm-crypt


On 09/10/2015 03:47 PM, andrea rota wrote:
> hi,
> 
> i recently created a new LUKS container via cryptsetup luksFormat on a
> workstation and migrated some data to it; when connecting the same HDD
> (eSATA) to a different box (a CuBox-i2eX) i am unable to luksOpen the
> container. i checked the dm-crypt FAQ and i must be missing something
> obvious as all the checks suggested there seem fine.

Hi,

it should work

This could be the problem I guess:

> name         : __xts-aes-neonbs
...

So it is using NEON acceleration on ARM.

There was a bug in NEON kernel implementation, see
http://www.saout.de/pipermail/dm-crypt/2015-February/004632.html

Could you read that thread and try workaround I mentioned there?
http://www.saout.de/pipermail/dm-crypt/2015-February/004631.html

Milan

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dm-crypt] luks container created on a system won't luksOpen on another
  2015-09-10 14:14 ` Milan Broz
@ 2015-09-10 15:19   ` andrea rota
  0 siblings, 0 replies; 3+ messages in thread
From: andrea rota @ 2015-09-10 15:19 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

hi Milan,

On Thu, Sep 10, 2015 at 04:14:39PM +0200, Milan Broz wrote:
[...]
> This could be the problem I guess:
> 
> > name         : __xts-aes-neonbs
> ...
> 
> So it is using NEON acceleration on ARM.
> 
> There was a bug in NEON kernel implementation, see
> http://www.saout.de/pipermail/dm-crypt/2015-February/004632.html
> 
> Could you read that thread and try workaround I mentioned there?
> http://www.saout.de/pipermail/dm-crypt/2015-February/004631.html

spot on...

the kernel i was using has all the crypto ciphers compiled in so i
couldn't unload the aes_arm_bs cipher, but looking at your other
message (re patch for the kernel bug) i installed a newer kernel that
includes the NEON patch and this works perfectly, thank you!

best
andrea

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1513 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-09-10 15:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-10 13:47 [dm-crypt] luks container created on a system won't luksOpen on another andrea rota
2015-09-10 14:14 ` Milan Broz
2015-09-10 15:19   ` andrea rota

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.