cryptsetup problem on rpi2 w 512bit (works on rpi, x86_64)

[jernst]

This should be working:
$this->bbcode_second_pass_code('', '# 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, and the Raspberry PI 1. However, it fails on the Raspberry Pi 2 with:
$this->bbcode_second_pass_code('', 'No key available with this passphrase.')

If I create the encrypted image on the rpi2, I can open it on the rpi or x86_64. However, I cannot open any image on the rpi2, regardless where it was created.

Anybody else observing this?

UPDATE: I took the same external hard drive that contains my encrypted image, and connected it to a BeagleBone Black. Guess what: it opens there just fine.
UPDATE: If I set the key-size above to 256, it works. 512 does not work with "No key available with this passphrase."

[thinkingeye]

The same problem here.

I had an external Drive created on the Raspbian os on raspberry pi 2 with 512 keysize. It opens just fine, but if I switch to the arch linux os on raspberry pi 2 it doesnt open.

I recreated an cryptsetup container with the 512 keysize setting on the arch linux version. If I try to open and put in the password, it says "no key available with this passphrase", then it display me a password prompt again. if I NOW put in the same password it opens... ??? Wtf.

In summary (because of my bad English):
first password try: "no key available with this passphrase"
seciond password try: it opens

[jernst]

Always great to know that I'm not entirely insane. I posted about this to the developer list here and am about to do what those guys told me to do.

[pepedog]

Something on my mind about kernel mode neon on imx6, can't find it now

[jernst]

pepedog: my (very limited) understanding is that neon is all about floating-point. How would that affect crypto operations?

[jernst]

Guys on the dm-crypt mailing list suggested blacklisting the following kernel modules:

• blacklist af_alg
• blacklist algif_skcipher

and voila, the problem goes away.

So it seems that gives us a big hint where the issue might lie.

[jernst]

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

http://www.saout.de/pipermail/dm-crypt/ ... 04631.html