Re: Status in 2007 of: loop-aes VS dm-crypt VS truecrypt

Christian Kujau <[email protected]>
Newsgroups gmane.linux.cryptography
Message-ID <[email protected]>
Hi Jari,

thanks for elaborating a bit on these issues, your comments are quite 
interesting to me. I tried to create the sceneario you described, 
however I'm not sure if I've done everything right:

On Wed, 30 May 2007, Jari Ruusu wrote:
> 1)  Set up a small dm-crypt essiv AES encrypted device

# dd if=/dev/zero of=/tmp/disk1.img count=50 bs=1M
# sudo losetup /dev/loop/0  /tmp/disk1.img
# sudo losetup /dev/loop/0
/dev/loop/0: [000f]:1575167 (/tmp/disk1.img)
# head -c 2880 /dev/urandom|uuencode -m -|head -n 65|tail -n 64|gpg -ac --cipher-algo aes256 --digest-algo SHA512 > /tmp/k.gpg
# gpg -d /tmp/k.gpg 2>/dev/null | sudo cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 192 /dev/loop0
# gpg -d /tmp/k.gpg 2>/dev/null | sudo cryptsetup luksOpen /dev/loop0 test1
# sudo cryptsetup status test1
/dev/mapper/test1 is active:
   cipher:  aes-cbc-essiv:sha256
   keysize: 192 bits
   device:  /dev/loop0
   offset:  1544 sectors
   size:    100856 sectors
   mode:    read/write

> 2)  Write some data to to plaintext device

# ls -lgo words && head -1 words
-rw-r--r-- 1 9728 May 31 23:51 words
Abelard
# sudo dd if=words of=/dev/mapper/test1

> 3)  Save copy of ciphertext

(I noticed that I had to close the test1, to get the data down to the 
loop0)

# sudo cryptsetup luksClose test1
# sudo dd if=/dev/loop0 of=test1.loop0
# sha1sum test1.loop0
9653a783668f453903bdad23ac2c8a87bfe52807  test1.loop0

> 4)  Write same data again, but with first byte of some 512 byte sector
>    altered.

Hm, I tried:
# dd if=words 2>/dev/null | sed 's/^Abelard$/9belard/' | head -1
9belard
# dd if=words 2>/dev/null | sed 's/^Abelard$/9belard/' | sudo dd of=/dev/mapper/test1
# sudo cryptsetup luksClose test1
# sudo dd if=/dev/loop0 of=test1.loop0.altered

> 5)  Compare previous and current ciphertexts. You will notice ciphertexts
>    will differ on first cipherblock within that 512 byte sector. This
>    leaked that there was plaintext change within first plaintext block
>    inside that 512 byte sector.

# sha1sum test1.loop0 test1.loop0.altered
9653a783668f453903bdad23ac2c8a87bfe52807  test1.loop0
9f68c329de554ccf6f0a81c3d3a21ef47410b9bf  test1.loop0.altered

# cmp -b test1.loop0 test1.loop0.altered
test1.loop0 test1.loop0.altered differ: byte 790529, line 373 is 234 M-^\ 201 M-^A
# od -x test1.loop0 > test1.loop0.hex
# od -x test1.loop0.altered > test1.loop0.altered.hex
diff -u test1.loop0.hex test1.loop0.altered.hex | wc -l
73

> 6)  Save copy of ciphertext

done (test1.loop0)

> 7)  Now modify plaintext data again, alter 130th byte of some 512 byte
>    sector.

Hm, a bit trickyer for me, I used dd/vi to alter the "words" file:

# vi words
[...]
# gpg -d  /tmp/k.gpg 2>/dev/null | sudo cryptsetup luksOpen /dev/loop0 test1
# dd if=words 2>/dev/null | sudo dd of=/dev/mapper/test1
# sudo cryptsetup luksClose test1
# sudo dd if=/dev/loop0 of=test1.loop0.altered.130

> 8)  Compare previous and current ciphertexts. You will notice ciphertexts
>    will differ on 9th cipherblock within that 512 byte sector. This leaked
>    that there was plaintext change within 9th plaintext block inside that
>    512 byte sector.

# sha1sum test1.loop0 test1.loop0.altered test1.loop0.altered.130
9653a783668f453903bdad23ac2c8a87bfe52807  test1.loop0
9f68c329de554ccf6f0a81c3d3a21ef47410b9bf  test1.loop0.altered
5dc0e66f0ff0d37959bf9cd43bb0433ecaae6728  test1.loop0.altered.130

# cmp  -b test1.loop0.altered test1.loop0.altered.130
test1.loop0.altered test1.loop0.altered.130 differ: byte 790529, line 373 is 201 M-^A 234 M-^\
# diff -u test1.loop0.altered.hex test1.loop0.altered.130.hex | wc -l
113

...While I'm not sure if the "9th plaintext block" I notice that the 
line# is the same and the values swapped. spooky :)

> 9)  Save copy of ciphertext

done (test1.loop0)

> 10) Modify plaintext data again, alter last byte of some 512 byte sector.

Again, with vi(1):

# vi words
[...]
# gpg -d  /tmp/k.gpg 2>/dev/null | sudo cryptsetup luksOpen /dev/loop0 test1
# dd if=words 2>/dev/null | sudo dd of=/dev/mapper/test1
# sudo cryptsetup luksClose test1

> 11) Compare previous and current ciphertexts. You will notice ciphertexts
>    will differ on last cipherblock within that 512 byte sector. This leaked
>    that there was plaintext change within last plaintext block inside that
>    512 byte sector.

# cmp test1.loop0.altered.130 test1.loop0.altered.512
test1.loop0.altered.130 test1.loop0.altered.512 differ: char 791025, line 376

# diff -u test1.loop0.altered.130.hex test1.loop0.altered.512.hex | wc -l
11

In case someone is interested, I've put all the .hexfiles and the diffs 
on: http://nerdbynature.de/bits/dm-crypt-fun/

> If you do above test with loop-AES version 2 or 3 on-disk format, you will
> notice that all cipherblocks within the 512 byte sector change regardless of
> where changed plaintext data is, thus hiding what location was changed.

I'll do this tomorrow, after getting some sleep. I'm surprised that this 
(already known) issue has not been addressed in dm-crypt. Yes, I know 
about the flamewars dm-crypt vs. loop-aes vs. whatnot but that's no 
excuse for not documenting this flaw (I said 'documenting', because how 
can someone *expect* to get a bug fixed in the OSS world ;)).

> loop-AES still leaks what 512 byte sectors have been modified, because full
> 512 byte sector ciphertexts will be different, but such significantly lower
> resolution is much better than adversary being able to pinpoint changes
> inside 512 byte sector.

Hm, would it be possible to get this note into the loop-AES.README, 
maybe under "8. Security levels"?

Thank you for your time,
Christian.
-- 
BOFH excuse #247:

Due to Federal Budget problems we have been forced to cut back on the number of users able to access the system at one time. (namely none allowed....)

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.