# Cryptoloop AES on x86-64 cannot decrypt file from x86-32

## nixscripter

I have a filesystem encrypted with AES in a file. It's not a dm-crypt volume, even though it probably should be. It's just an XFS filesystem in a giant file, with AES ran over it.

I generated it on a 32-bit system and it mounts fine over a cryptoloop loopback device. On my 64-bit system, the decrypt appears to succeed, but does the math incorrectly. There is no error, but mount doesn't recognize the contents of the loopback device as an XFS file system. The command used to mount the volume is the same. It works on the 32-bit machine and fails on the 64-bit machine:

```
mount -o loop,encryption=aes file.xfs /mnt/dir
```

On the 64-bit machine, it just says "failed, check dmesg", and in it I find:

```
Nov 20 21:57:21 gentooquad XFS: bad magic number

Nov 20 21:57:21 gentooquad XFS: SB validate failed

```

I've checked the relevant kernel modules: cryptoloop, aes, and cbc (which is just a guess, I don't know if it's needed). The only difference I see is that cbc is built-into the kernel on the 64-bit machine.

I've made really sure I'm typing the same password, adding -p for standard input to verify it.

What else am I missing? There are so many moving pieces...

----------

## Hu

Why do you think that the decryption succeeds on the 64-bit host?  As far as I know, Some of the early cryptographic schemes, which I think includes cryptoloop, had no verification, so an incorrect passphrase could succeed, but present garbage data because the key was wrong.

The documentation for cryptoloop says that it is not safe for use on journaling filesystems.  XFS is a journaling filesystem.  I suggest you convert to a dm-crypt based loopback as soon as possible.

----------

## nixscripter

If I might clarify: "succeed" meant "the algorithm was found and executed," as opposed to throwing an error like "invalid argument" (which it did before I loaded the aes module).

Thanks for the tip about the journaling, but converting might take a while. Is there a way to turn journaling off on XFS for the time being?

I would also like to figure this out, whether it's sort of real incompatibility between implementations of AES in the kernel. While I expect it's a mistake on my part, the other possibility would be a really bad thing.

----------

## Hu

I do not use XFS, so I do not know whether you can disable journaling for it.  For the other problem, I think the first step would be to set up the cryptoloop independent of trying to mount it, so you can check whether both systems see the same plaintext for a given key.

----------

## nixscripter

I did this on both machines:

```

(root) # losetup -e aes /dev/loop1 file.disc

Password:

(root) # xxd /dev/loop1 | less

```

The result: not even close.

32-bit (correct) starts with:

```
 0000000: 5846 5342 0000 1000 0000 0000 0000 3000  XFSB..........0.
```

64-bit (incorrect) starts with:

```
0000000: ba8f c727 3acf a357 9058 17a9 0878 bc28  ...':..W.X.....(
```

Is it something like key length? CBC versus EBC?

I'm running out of ideas, and really don't think this is a bug...

(I am changing my XFS loopback disks to cryptsetup, by the way.)

----------

## selig

Actually cryptoloop is safe with journals but only if the underlying device is a real block device, not a file. And no, you cannot turn off the journalling with XFS. The only FS I know which can disable the journal is ext3 when you mount it as ext2.

----------

## eminenz

 *selig wrote:*   

> Actually cryptoloop is safe with journals but only if the underlying device is a real block device, not a file. And no, you cannot turn off the journalling with XFS. The only FS I know which can disable the journal is ext3 when you mount it as ext2.

 

as far as i know encfs uses cryptoloop. it mounts an encrypted folder on a disk as the unencrypted folder somewhere else (provided the right key was given). 

Do you know whether that's safe, too, or do you know how where to find out?

----------

## selig

I do not know how encfs exactly works but I think that if it takes files from the "mounted" encrypted directory, encrypts them and puts them into the "source" directory then it should be safe. However, if it creates a loop device with cryptoloop inside the "source" directory and then uses this as the backend for encrypting files in the mounted encrypted directory then it is not safe. But I guess it is the first case so it should be fine. Try to look at encfs documentation on how it does the encryption, or simply try to set up encfs yourself and look at the files it produces.

----------

