Is this watermarking issue still insufficiently addressed in dm-crypt as
of today? Doing the following test, seems to produce a 16-byte change in
the ciphertext, I'd appreciate knowing if there is something wrong in
the methodology here:
# lvcreate --name test --size 12M vg_squeak0
# cryptsetup luksFormat /dev/mapper/vg_squeak0-test
# cryptsetup luksOpen /dev/mapper/vg_squeak0-test test
This is using:
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
# dd if=/dev/zero of=/dev/mapper/test
# mkdir cryptotest
# dd if=/dev/mapper/vg_squeak0-test of=cryptotest/before
# echo -n a > cryptotest/mod
# dd if=cryptotest/mod of=/dev/mapper/test bs=1 seek=$((51200-1)) count=1
# sync
# dd if=/dev/mapper/vg_squeak0-test of=cryptotest/after
# cmp -l cryptotest/{before,after} | wc -l
This shows that 16-bytes changed.
dont forget to cleanup:
# cryptsetup luksClose test
Using the loop-aes multi-key v3 method described here:
Jari Ruusu <jariruusu@xxxxxxxxxxxxxxxxxxxxx> writes:
> # dd if=/dev/zero of=/tmp/test1 bs=1024 count=1 2>/dev/null
> # head -c 2925 /dev/urandom | uuencode -m - | head -n 66 | tail -n 65 | losetup -e AES256 -p 0 /dev/loop7 /tmp/test1
> # losetup /dev/loop7
> /dev/loop7: [0703]:16 (/tmp/test1) encryption=AES256 multi-key-v3
> # dd if=/dev/zero of=/dev/loop7 conv=notrunc bs=1024 count=1 2>/dev/null
> # sync
> # od -Ax -tx1 /tmp/test1 >/tmp/hex1
> # echo -n X | dd of=/dev/loop7 conv=notrunc bs=1 seek=0 count=1 2>/dev/null
> # sync
> # od -Ax -tx1 /tmp/test1 >/tmp/hex2
> # echo -n X | dd of=/dev/loop7 conv=notrunc bs=1 seek=129 count=1 2>/dev/null
> # sync
> # od -Ax -tx1 /tmp/test1 >/tmp/hex3
> # echo -n X | dd of=/dev/loop7 conv=notrunc bs=1 seek=255 count=1 2>/dev/null
> # sync
> # od -Ax -tx1 /tmp/test1 >/tmp/hex4
> # losetup -d /dev/loop7
> # diff /tmp/hex1 /tmp/hex2 | head -n 2
> 1,32c1,32
> < 000000 c9 a4 d9 03 a6 fd 37 a5 8e e7 8c a7 4d 82 a6 bc
> # diff /tmp/hex2 /tmp/hex3 | head -n 2
> 1,32c1,32
> < 000000 fd b3 c1 17 4e 5c c4 5d 87 24 8d e6 de 19 5d 2a
> # diff /tmp/hex3 /tmp/hex4 | head -n 2
> 1,32c1,32
> < 000000 58 ba c8 f6 0e 99 74 73 f7 69 2c ad 03 bb 82 8d
>
> In above loop-AES version 3 on-disk format cases, regardless of where
> plaintext changes are, all 32 cipher blocks within 512 byte sector are
> changed. Above 'diff' commands show only one line of hex data, but if you
> read it carefully, that '1,32c1,32' string says that 32 lines of 16 bytes
> each are different.
I get the same results, and I see how the entire 512-byte sector changes
with each modification. However, why do you do the hexdumps? Why not
just store the actual data and do cmp -l | wc -l? I think the way you
are doing it, the first byte of each 16-byte block could have changed,
and the rest stayed the same, and you would still see 32*16=512 bytes of
difference where there was only 32:
Finally, one question... if I understand multi-key v3 properly, that means
that each subsequent sector (mod 64) uses a different key to encrypt the
data sectors and the 65th is used as additional input to the MD5 IV
computation.
I dont exactly know what the MD5 IV computation is specifically (how can
I find out?), but if multi-key just means that each subsequent sector
uses a different key then if we are making changes within one 512-byte
sector, then the multi-key piece shouldn't come into play here
Thanks for the clarifications,
Micah
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
