Garbage chars with AES encryption in CBC mode with openssl and dmsetup

0
votes

I got a strange problem. I filled a text file with the letter 'A' and made it 4096 bytes long. Then a encrypted it with openssl on linux:

KEY="2D242B65C517B72F8D1DAA8278CA5A2ED5D8A95BCF82BFD3778212218726335F" 
openssl enc -nosalt -iv 0 -K $KEY -aes-256-cbc -in $PLAINIMAGENAME -out $CRYPTIMAGENAME

(No salt, no IV)

Then a tried to create a device-mapper loopback device with dm-crypt:

losetup /dev/loop0 $CRYPTIMAGENAME
sudo dmsetup create cryptotest --table "0 4096 crypt aes-cbc-null $KEY 0 /dev/loop0 0"

When I try to read from /dev/mapper/cryptotest I get my A's, but every 512 bytes (block size?) there are 16 bytes of garbage. How is this possible?

When I use the ECB-mode (where every block is encrypted in the same way) everything works fine.

By the way I don't want to use LUKS for loopback encryption, I need a headerless AES stream which can be created by openssl or aespipe.

1
linuxencryptionopensslcryptographyaes
It's the padding: en.wikipedia.org/wiki/Padding_(cryptography) – Artjom B.
Note that the AES block size is 16 bytes. – zaph
I believe dm-crypt uses CBC mode with no padding. That's because a disk sector is a fixed size and always a multiple of block size. I find it odd that both ECB and CBC mode to decrypt the block. – jww

1 Answers

2
votes

I found the solution to the problem:

The device-mapper needs to start a new CBC every sector (512 bytes == 32 AES blocks) to be able to have random-access to the sectors without having to decrypt everything before that. Therefore I have to concatenate aes-128-cbc encryption streams with a length of 512. Of course an IV of zeros is not good at all. I use aes-128-cbc-essiv:sha256 now. The ESSIV is calculated with a hash (sha256) of the encryption key and the sector number, so no sector has the same encrypted data.

Further information can be found here: http://www.penzin.net/dmcrypt/