[dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

TL;DR: 
    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
cannot be opened again on the new Raspberry Pi 2. Shorter key-size, and other platforms work.

This is a bit a puzzler to me …

This is what I do:
    # Create 8M image
    dd if=/dev/zero of=./test.img count=8 bs=1M
    # Set up encryption -- enter a suitable password when asked
    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
    # Now attempt to open it, entering the same password
    cryptsetup open test.img test

and indeed it works for me on x86_64, the Raspberry PI 1, and the BeagleBone Black. However, it fails on the Raspberry Pi 2 with:
	"No key available with this passphrase."

If I create the encrypted image on the Raspberry Pi 2, I can open it on other platforms. However, I cannot open any image with these parameters on the Raspberry Pi 2, regardless where it was created.

If I set the key-size to 256 bit, it works on all platforms.

The Raspberry Pi 2 is an ARM v7 processor, unlike the Raspberry Pi 1. But then, the BeagleBone Black is Arm V7, too.

Puzzled ...




Johannes.

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Lars Winterfeld]

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

Hi.

You could add another keyslot with a keyfile and open the device with
that to be absolutely sure you did not just miss-type the password
(because of a different keyboard layout on the Raspberry Pi 2 etc.)



On 20.02.2015 22:37, Johannes Ernst wrote:
> TL;DR: 
>     cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
> cannot be opened again on the new Raspberry Pi 2. Shorter key-size, and other platforms work.
> 
> This is a bit a puzzler to me …
> 
> This is what I do:
>     # Create 8M image
>     dd if=/dev/zero of=./test.img count=8 bs=1M
>     # Set up encryption -- enter a suitable password when asked
>     cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>     # Now attempt to open it, entering the same password
>     cryptsetup open test.img test
> 
> and indeed it works for me on x86_64, the Raspberry PI 1, and the BeagleBone Black. However, it fails on the Raspberry Pi 2 with:
> 	"No key available with this passphrase."
> 
> If I create the encrypted image on the Raspberry Pi 2, I can open it on other platforms. However, I cannot open any image with these parameters on the Raspberry Pi 2, regardless where it was created.
> 
> If I set the key-size to 256 bit, it works on all platforms.
> 
> The Raspberry Pi 2 is an ARM v7 processor, unlike the Raspberry Pi 1. But then, the BeagleBone Black is Arm V7, too.
> 
> Puzzled ...
> 
> 
> 
> 
> Johannes.
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

It’s not the keyboard layout: I interact with both Pi’s through ssh and terminal on OSX. And it even happens with extremely simple pass phrases such as ‘asdf’.


> On Feb 20, 2015, at 14:25, Lars Winterfeld <lars.winterfeld@tu-ilmenau.de> wrote:
> 
> Hi.
> 
> You could add another keyslot with a keyfile and open the device with
> that to be absolutely sure you did not just miss-type the password
> (because of a different keyboard layout on the Raspberry Pi 2 etc.)
> 
> 
> 
> On 20.02.2015 22:37, Johannes Ernst wrote:
>> TL;DR: 
>>    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>> cannot be opened again on the new Raspberry Pi 2. Shorter key-size, and other platforms work.
>> 
>> This is a bit a puzzler to me …
>> 
>> This is what I do:
>>    # Create 8M image
>>    dd if=/dev/zero of=./test.img count=8 bs=1M
>>    # Set up encryption -- enter a suitable password when asked
>>    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>>    # Now attempt to open it, entering the same password
>>    cryptsetup open test.img test
>> 
>> and indeed it works for me on x86_64, the Raspberry PI 1, and the BeagleBone Black. However, it fails on the Raspberry Pi 2 with:
>> 	"No key available with this passphrase."
>> 
>> If I create the encrypted image on the Raspberry Pi 2, I can open it on other platforms. However, I cannot open any image with these parameters on the Raspberry Pi 2, regardless where it was created.
>> 
>> If I set the key-size to 256 bit, it works on all platforms.
>> 
>> The Raspberry Pi 2 is an ARM v7 processor, unlike the Raspberry Pi 1. But then, the BeagleBone Black is Arm V7, too.
>> 
>> Puzzled ...
>> 
>> 
>> 
>> 
>> Johannes.
>> 
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Milan Broz]

On 02/20/2015 11:59 PM, Johannes Ernst wrote:
> It’s not the keyboard layout: I interact with both Pi’s through ssh and terminal on OSX. And it even happens with extremely simple pass phrases such as ‘asdf’.

Hi,

it is very unlikely cryptsetup problem but I would guess some kernel crypt or library ARM glitch.
(Cryptsetup is tested even on new ARM64 and there is not many platform dependent code.)

Whatever, please send me full output from that command with added --debug.
I always need exact versions of kernel, crypto libraries a obviously cryptsetup.

(If us use other hash it works even on Pi? Try sha1 and sha256 at least.)

Thanks,
Milan

> 
> 
>> On Feb 20, 2015, at 14:25, Lars Winterfeld <lars.winterfeld@tu-ilmenau.de> wrote:
>>
>> Hi.
>>
>> You could add another keyslot with a keyfile and open the device with
>> that to be absolutely sure you did not just miss-type the password
>> (because of a different keyboard layout on the Raspberry Pi 2 etc.)
>>
>>
>>
>> On 20.02.2015 22:37, Johannes Ernst wrote:
>>> TL;DR: 
>>>    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>>> cannot be opened again on the new Raspberry Pi 2. Shorter key-size, and other platforms work.
>>>
>>> This is a bit a puzzler to me …
>>>
>>> This is what I do:
>>>    # Create 8M image
>>>    dd if=/dev/zero of=./test.img count=8 bs=1M
>>>    # Set up encryption -- enter a suitable password when asked
>>>    cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>>>    # Now attempt to open it, entering the same password
>>>    cryptsetup open test.img test
>>>
>>> and indeed it works for me on x86_64, the Raspberry PI 1, and the BeagleBone Black. However, it fails on the Raspberry Pi 2 with:
>>> 	"No key available with this passphrase."
>>>
>>> If I create the encrypted image on the Raspberry Pi 2, I can open it on other platforms. However, I cannot open any image with these parameters on the Raspberry Pi 2, regardless where it was created.
>>>
>>> If I set the key-size to 256 bit, it works on all platforms.
>>>
>>> The Raspberry Pi 2 is an ARM v7 processor, unlike the Raspberry Pi 1. But then, the BeagleBone Black is Arm V7, too.
>>>
>>> Puzzled ...
>>>
>>>
>>>
>>>
>>> Johannes.

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

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

I originally posted this to the Arch Linux ARM forum here: http://archlinuxarm.org/forum/viewtopic.php?f=60&t=8489 <http://archlinuxarm.org/forum/viewtopic.php?f=60&t=8489>
where since, somebody else reported seeing something (almost) identical: taking his external drive from an Raspberry Pi 1 to a Raspberry Pi 2 where it failed to open.

He says, however, that cryptsetup open succeeds on the second (!) attempt putting in his password. However, this does not work for me. This is beginning to smell like some kind of memory initialization problem.

—debug output coming in just a sec.


> On Feb 20, 2015, at 22:53, Milan Broz <gmazyland@gmail.com> wrote:
> 
> On 02/20/2015 11:59 PM, Johannes Ernst wrote:
>> It’s not the keyboard layout: I interact with both Pi’s through ssh and terminal on OSX. And it even happens with extremely simple pass phrases such as ‘asdf’.
> 
> Hi,
> 
> it is very unlikely cryptsetup problem but I would guess some kernel crypt or library ARM glitch.
> (Cryptsetup is tested even on new ARM64 and there is not many platform dependent code.)
> 
> Whatever, please send me full output from that command with added --debug.
> I always need exact versions of kernel, crypto libraries a obviously cryptsetup.
> 
> (If us use other hash it works even on Pi? Try sha1 and sha256 at least.)
> 
> Thanks,
> Milan
> 
>> 
>> 
>>> On Feb 20, 2015, at 14:25, Lars Winterfeld <lars.winterfeld@tu-ilmenau.de> wrote:
>>> 
>>> Hi.
>>> 
>>> You could add another keyslot with a keyfile and open the device with
>>> that to be absolutely sure you did not just miss-type the password
>>> (because of a different keyboard layout on the Raspberry Pi 2 etc.)
>>> 
>>> 
>>> 
>>> On 20.02.2015 22:37, Johannes Ernst wrote:
>>>> TL;DR: 
>>>>   cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>>>> cannot be opened again on the new Raspberry Pi 2. Shorter key-size, and other platforms work.
>>>> 
>>>> This is a bit a puzzler to me …
>>>> 
>>>> This is what I do:
>>>>   # Create 8M image
>>>>   dd if=/dev/zero of=./test.img count=8 bs=1M
>>>>   # Set up encryption -- enter a suitable password when asked
>>>>   cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
>>>>   # Now attempt to open it, entering the same password
>>>>   cryptsetup open test.img test
>>>> 
>>>> and indeed it works for me on x86_64, the Raspberry PI 1, and the BeagleBone Black. However, it fails on the Raspberry Pi 2 with:
>>>> 	"No key available with this passphrase."
>>>> 
>>>> If I create the encrypted image on the Raspberry Pi 2, I can open it on other platforms. However, I cannot open any image with these parameters on the Raspberry Pi 2, regardless where it was created.
>>>> 
>>>> If I set the key-size to 256 bit, it works on all platforms.
>>>> 
>>>> The Raspberry Pi 2 is an ARM v7 processor, unlike the Raspberry Pi 1. But then, the BeagleBone Black is Arm V7, too.
>>>> 
>>>> Puzzled ...
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Johannes.


[-- Attachment #2: Type: text/html, Size: 4456 bytes --]

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

Transcript. Note that adding the —debug flag successfully opens on the *second* attempt entering the password. Without —debug, no such luck.

> dd if=/dev/zero of=./test.img count=8 bs=1M
> cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img

used password ‘asdf’ (no quotes)

> cryptsetup open test.img test
Enter passphrase for test.img: 
No key available with this passphrase.
Enter passphrase for test.img: 
No key available with this passphrase.
^C
Enter passphrase for test.img: Error reading passphrase from terminal.

> cryptsetup open --debug test.img test
# cryptsetup 1.6.6 processing "cryptsetup open --debug test.img test"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device test.img context.
# Trying to open and read device test.img.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device test.img.
# Crypto backend (gcrypt 1.6.2) initialized.
# Detected kernel Linux 3.18.7-5-ARCH armv7l.
# Reading LUKS header of size 1024 from device test.img
# Key length 64, device size 16384 sectors, header size 4036 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume test [keyslot -1] using [none] passphrase.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.28.0.
# Device-mapper backend running with UDEV support enabled.
# dm status test  OF   [16384] (*1)
# Interactive passphrase entry requested.
Enter passphrase for test.img: 
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Trying to open key slot 1 [INACTIVE].
# 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.
Enter passphrase for test.img: 
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
Key slot 0 unlocked.
# Allocating a free loop device.
# Trying to open and read device /dev/loop1.
# Calculated device size is 12288 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-81fb41f7c33c4c0aa9af442ed6230f5f-test
# Udev cookie 0xd4db383 (semid 2785282) created
# Udev cookie 0xd4db383 (semid 2785282) incremented to 1
# Udev cookie 0xd4db383 (semid 2785282) incremented to 2
# Udev cookie 0xd4db383 (semid 2785282) assigned to CREATE task(0) with flags         (0x0)
# dm create test CRYPT-LUKS1-81fb41f7c33c4c0aa9af442ed6230f5f-test OF   [16384] (*1)
# dm reload test  OFW    [16384] (*1)
# dm resume test  OFW    [16384] (*1)
# test: Stacking NODE_ADD (253,1) 0:0 0600 [verify_udev]
# test: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4db383 (semid 2785282) decremented to 1
# Udev cookie 0xd4db383 (semid 2785282) waiting for zero
# Udev cookie 0xd4db383 (semid 2785282) destroyed
# test: Processing NODE_ADD (253,1) 0:0 0600 [verify_udev]
# test: Processing NODE_READ_AHEAD 256 (flags=1)
# test (253:1): read ahead is 256
# test: retaining kernel read ahead of 256 (requested 256)
# Releasing crypt device test.img context.
# Releasing device-mapper backend.
# Closed loop /dev/loop1 (test.img).
# Unlocking memory.
Command successful.

This is Arch Linux ARM for the Raspberry Pi 2:
> uname -a
Linux rpi2 3.18.7-5-ARCH #1 SMP PREEMPT Wed Feb 18 20:56:17 MST 2015 armv7l GNU/Linux

Packages involved (tell me what else you need):
> pacman -Qi cryptsetup
Name           : cryptsetup
Version        : 1.6.6-1

> pacman -Qi libgcrypt
Name           : libgcrypt
Version        : 1.6.2-1

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

> (If us use other hash it works even on Pi? Try sha1 and sha256 at least.)

It appears independent of the hash involved: I tried sha1, sha256 in addition to the original sha256. The behavior is the same:
1. cryptsetup open … does not open
2. cryptsetup open —debug opens on the second attempt to put the password in.

Cheers,



Johannes.

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Milan Broz]

On 02/22/2015 08:40 PM, Johannes Ernst wrote:
>> (If us use other hash it works even on Pi? Try sha1 and sha256 at least.)
> 
> It appears independent of the hash involved: I tried sha1, sha256 in addition to the original sha256. The behavior is the same:
> 1. cryptsetup open … does not open
> 2. cryptsetup open —debug opens on the second attempt to put the password in.

ok, this is really strange.


One (random) guess from the log:

> # Using userspace crypto wrapper to access keyslot area.

it means that code is using kernel userspace crypto
(and cryptsetup already revealed at least two problems there...)

Could you try it without it? (Code should fallback to old dmcrypt temporary devices mode).

You can do it either by

 - disabling/blacklisting kernel modules which provides it: af_alg.ko and algif_skcipher.ko
  (or disable CRYPTO_USER_API, CRYPTO_USER_API_SKCIPHER when compiling kernel)

 - try to run older cryptsetup (at least 1.6.4 or older)

I am afraid I cannot help more here without reproducing it...
(Is it RPI2 only issue or anyone see it on other ARM device?)

Milan

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

1. There was a (cryptic, to me) comment by one of the core Arch Linux ARM developers on my post. He said "Something on my mind about kernel mode neon on imx6, can't find it now” (http://archlinuxarm.org/forum/viewtopic.php?f=60&t=8489&p=45395#p45364) I have little idea what this could mean, but I figure I pass it on in case somebody here does.

2. I disabled the mentioned kernel modules:

    blacklist af_alg
    blacklist algif_skcipher

and, magic happens, it behaves as intended: cryptsetup opens file on first try.

3. When the kernel modules get added again, with the image file created in step #2, I’m back to "No key available with this passphrase.”.

4. This seems to be a Raspberry PI 2 (ARMv7)-only issue, it seems to work on Raspberry PI 1 (ARMv6) and on BeagleBone Black (ARMv7). 

5. If you send me an ssh public key, I'd be happy to set you up with a shell on my Raspberry PI 2, if there is a chance that it might help in any way. 


> On Feb 22, 2015, at 12:20, Milan Broz <gmazyland@gmail.com> wrote:
> 
> On 02/22/2015 08:40 PM, Johannes Ernst wrote:
>>> (If us use other hash it works even on Pi? Try sha1 and sha256 at least.)
>> 
>> It appears independent of the hash involved: I tried sha1, sha256 in addition to the original sha256. The behavior is the same:
>> 1. cryptsetup open … does not open
>> 2. cryptsetup open —debug opens on the second attempt to put the password in.
> 
> ok, this is really strange.
> 
> 
> One (random) guess from the log:
> 
>> # Using userspace crypto wrapper to access keyslot area.
> 
> it means that code is using kernel userspace crypto
> (and cryptsetup already revealed at least two problems there...)
> 
> Could you try it without it? (Code should fallback to old dmcrypt temporary devices mode).
> 
> You can do it either by
> 
> - disabling/blacklisting kernel modules which provides it: af_alg.ko and algif_skcipher.ko
>  (or disable CRYPTO_USER_API, CRYPTO_USER_API_SKCIPHER when compiling kernel)
> 
> - try to run older cryptsetup (at least 1.6.4 or older)
> 
> I am afraid I cannot help more here without reproducing it...
> (Is it RPI2 only issue or anyone see it on other ARM device?)
> 
> Milan

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Milan Broz]

On 02/23/2015 07:44 PM, Johannes Ernst wrote:
> 1. There was a (cryptic, to me) comment by one of the core Arch Linux
> ARM developers on my post. He said "Something on my mind about kernel
> mode neon on imx6, can't find it now”
> (http://archlinuxarm.org/forum/viewtopic.php?f=60&t=8489&p=45395#p45364)
> I have little idea what this could mean, but I figure I pass it on in
> case somebody here does.
> 
> 2. I disabled the mentioned kernel modules:
> 
> blacklist af_alg blacklist algif_skcipher
> 
> and, magic happens, it behaves as intended: cryptsetup opens file on
> first try.

Ok, so it means there is something wrong when using AF_ALG/SKCIPHER
on new Raspberry Pi2.
(Please can you post luksDump as well - just to be sure which mode
and cipher it is - I guess it is aes-xts but cannot find it in log.)

CC kernel crypto api list ... maybe someone knows about known problem here.

The link to failing cryptsetup debug log for reference:
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7973

Thanks,
Milan

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Johannes Ernst]

All in one place:

> dd if=/dev/zero of=./test.img count=8 bs=1M

> cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
Used password ‘asdf’ (no quotes)

> cryptsetup open test.img test
Enter passphrase for test.img: 
No key available with this passphrase.
Enter passphrase for test.img: 
No key available with this passphrase.
^C

> cryptsetup luksDump test.img     
LUKS header information for test.img

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha512
Payload offset:	4096
MK bits:       	512
MK digest:     	a6 c0 8d f7 f8 db b0 95 77 b7 72 09 3f 8f 86 ff 6f 31 0b a1 
MK salt:       	1c 9f 21 cf 2c 81 26 49 cc 36 a0 3a 6d 9e 49 a3 
               	43 3d a7 38 7d 12 86 5b 4e df f9 ac 38 1c a4 38 
MK iterations: 	1000
UUID:          	d4a0b4ab-b15e-4faf-8504-7e01d88dd9de

Key Slot 0: ENABLED
	Iterations:         	4289
	Salt:               	3c 8b 2e de 72 3f 17 5c 4c 3b d3 ca 5e 09 77 11 
	                      	69 10 1d 54 ab de c8 87 f9 fd 76 b5 e4 13 1e 04 
	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

> cryptsetup open --debug test.img test
# cryptsetup 1.6.6 processing "cryptsetup open --debug test.img test"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device test.img context.
# Trying to open and read device test.img.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device test.img.
# Crypto backend (gcrypt 1.6.2) initialized.
# Detected kernel Linux 3.18.7-5-ARCH armv7l.
# Reading LUKS header of size 1024 from device test.img
# Key length 64, device size 16384 sectors, header size 4036 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume test [keyslot -1] using [none] passphrase.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.28.0.
# Device-mapper backend running with UDEV support enabled.
# dm status test  OF   [16384] (*1)
# Interactive passphrase entry requested.
Enter passphrase for test.img: 
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Trying to open key slot 1 [INACTIVE].
# 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.
Enter passphrase for test.img: 
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
Key slot 0 unlocked.
# Allocating a free loop device.
# Trying to open and read device /dev/loop5.
# Calculated device size is 12288 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-d4a0b4abb15e4faf85047e01d88dd9de-test
# Udev cookie 0xd4d3a56 (semid 720898) created
# Udev cookie 0xd4d3a56 (semid 720898) incremented to 1
# Udev cookie 0xd4d3a56 (semid 720898) incremented to 2
# Udev cookie 0xd4d3a56 (semid 720898) assigned to CREATE task(0) with flags         (0x0)
# dm create test CRYPT-LUKS1-d4a0b4abb15e4faf85047e01d88dd9de-test OF   [16384] (*1)
# dm reload test  OFW    [16384] (*1)
# dm resume test  OFW    [16384] (*1)
# test: Stacking NODE_ADD (253,9) 0:0 0600 [verify_udev]
# test: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d3a56 (semid 720898) decremented to 1
# Udev cookie 0xd4d3a56 (semid 720898) waiting for zero
# Udev cookie 0xd4d3a56 (semid 720898) destroyed
# test: Processing NODE_ADD (253,9) 0:0 0600 [verify_udev]
# test: Processing NODE_READ_AHEAD 256 (flags=1)
# test (253:9): read ahead is 256
# test: retaining kernel read ahead of 256 (requested 256)
# Releasing crypt device test.img context.
# Releasing device-mapper backend.
# Closed loop /dev/loop5 (test.img).
# Unlocking memory.
Command successful.

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

[Milan Broz]

On 02/24/2015 12:02 AM, Johannes Ernst wrote:
> All in one place:
> 
>> dd if=/dev/zero of=./test.img count=8 bs=1M
> 
>> cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
> Used password ‘asdf’ (no quotes)
> 
>> cryptsetup open test.img test
> Enter passphrase for test.img: 
> No key available with this passphrase.
> Enter passphrase for test.img: 
> No key available with this passphrase.

I was able to reproduce it on Raspberry Pi2 B+ and indeed it is Neon code issue.
I am using Raspian, where all cryptocode is compiled as modules:

Without ARM aes_arm_bs module it works:

# echo xxx|src/cryptsetup open test.img --test-passphrase -v
Key slot 0 unlocked.
Command successful.

# modprobe aes_arm_bs

# echo xxx|src/cryptsetup open test.img --test-passphrase -v
device-mapper: reload ioctl on  failed: No such file or directory
Failed to setup dm-crypt key mapping for device test.img.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
Command failed with code 5: Input/output error

(Userspace crypto wrapper failed so code tries to use old dmcrypt temporary device,
errors above are not directly related to Neon issue.)

And in dmesg module even failed test:

[  318.445489] alg: skcipher: Chunk test 1 failed on decryption at page 0 for xts-aes-neonbs
[  318.445515] 00000000: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
[  318.445526] 00000010: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
[  318.445534] 00000020: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
[  318.445543] 00000030: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
[  318.445553] 00000040: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
[  318.445562] 00000050: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
[  318.445570] 00000060: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
[  318.445580] 00000070: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
[  318.445588] 00000080: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
[  318.445597] 00000090: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
[  318.445607] 000000a0: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
[  318.445616] 000000b0: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
[  318.445624] 000000c0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
[  318.445634] 000000d0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
[  318.445643] 000000e0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
[  318.445651] 000000f0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
[  318.445661] 00000100: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
[  318.445670] 00000110: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
[  318.445678] 00000120: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
[  318.445688] 00000130: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
[  318.445697] 00000140: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
[  318.445705] 00000150: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
[  318.445715] 00000160: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
[  318.445723] 00000170: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
[  318.445732] 00000180: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
[  318.445742] 00000190: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
[  318.445750] 000001a0: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
[  318.445759] 000001b0: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
[  318.445769] 000001c0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
[  318.445777] 000001d0: ab 1c bb 4c 15 50 be 97 f7 ab 40 66 19 3c 4c aa
[  318.445786] 000001e0: 5b 41 ef c3 ba 09 50 93 f2 c5 00 48

Seems there is an issue with the Neon AES implementation...

Milan