LUKS Cryptsetup Options Failing for Raspberry Pi 3 Model B+ Running Kali Linux ARM

I've scoured the internet for help on this, and it seems I'm one of the only people with this problem.

I recently downloaded a fresh copy of Kali Linux ARM for the Raspberry Pi 3 Model B+, and I want to set it up as a portable hacking station with an external encrypted media drive (encrypted with LUKS) that will be automatically unlocked at boot. I configured /etc/fstab and /etc/crypttab to correctly unlock and mount my encrypted partitions respectively (using a key file).

I noticed that this process would consistently fail on boot, giving the error that it "cannot allocate memory" when unlocking the drive through /etc/crypttab. After doing some more digging and testing, I found that the problem was only on the Raspberry Pi itself, because I could use the exact same key file to unlock the drive manually on my laptop: cryptsetup luksOpen --key-file /root/keyfile /dev/sdb1 sdb1_crypt. When I tried this same command on the Raspberry Pi, it would wait for a few seconds (just as it did on my laptop while it took time to unlock the drive), and finish with a successful error code. However, the drive would not be unlocked, and running lsblk would still show the locked drive (it also did not appear in /dev/mapper/sdb1_crypt), whereas the drive would be successfully unlocked when done on my laptop. The luksRemoveKey command also did not work on the Raspberry Pi. I didn't try every cryptsetup command, but I'm convinced that those aren't the only ones that don't work. Nevertheless, I could still use my password (key slot 0, and the key file was key slot 1) to unlock the drive on both devices: cryptsetup luksOpen /dev/sdb1 sdb1_crypt.

My guess is that the problem lies with the kernel, and I don't have the skills to fix it. I thought about posting this over at the Kali Linux forums, but I was hoping someone else might have the same problem on another OS that they fixed.

Thanks in advance, any help is appreciated.

I did a little more research into the memory warnings cryptsetup was giving me, and I found this post by @rscottbailey.

It turns out cryptsetup chooses some parameters that effectively are scaled based on the performance of your current system (in an attempt to reach some vaguely consistent level of "hardness"?) -- what works well for the Core i7 is too difficult for my Raspberry Pi.

My workaround, since I didn't have any data on the device yet that I couldn't regenerate, was to repeat the formatting operation on the rpi 3. This gave me something that was usable on both systems.

After reformatting my drive and creating a new LUKS partition from my Raspberry Pi 3 Model B+, the errors ceased to occur. To anyone else looking to create an encrypted LUKS partition on any external/portable drive, I suggest you encrypt it using the slowest/lowest-capacity device you have.