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