mjhjmtu

Are there, from a cryptanalysis point of view, security drawbacks when reusing the same key for different volumes in dm-crypt plain mode with cypher aes-xts-plain64?

# Example: Encrypt two volumes with the same key

cryptsetup --type plain --cipher=aes-xts-plain64 --key-size=256 --key-file mykey open /dev/sda myvol1
cryptsetup --type plain --cipher=aes-xts-plain64 --key-size=256 --key-file mykey open /dev/sdb myvol2

I'm only considering practical cases where less than, say, 100 volumes are encrypted with the same key.

Well, this isn't security stackexchange and I'm not a cryptography expert, but on the face of things:

Alice unencrypted:

00000000 48 65 6c 6c 6f 20 6d 79 20 6e 61 6d 65 20 69 73 |Hello my name is|
00000010 20 41 6c 69 63 65 0a 00 00 00 00 00 00 00 00 00 | Alice..........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Bobby unencrypted:

00000000 48 65 6c 6c 6f 20 6d 79 20 6e 61 6d 65 20 69 73 |Hello my name is|
00000010 20 42 6f 62 62 79 0a 00 00 00 00 00 00 00 00 00 | Bobby..........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Both encrypted with the same (master) key, aes-xts-plain64:

Alice000 8f 04 35 fc 9f cb 5d c8 af da ae 78 cd e5 64 3d |..5...]....x..d=|
Bobby000 8f 04 35 fc 9f cb 5d c8 af da ae 78 cd e5 64 3d |..5...]....x..d=|
Alice010 4f d3 99 77 7b c1 2c 8d ff 9b 4d 55 da a3 9b e2 |O..w{.,...MU....|
Bobby010 12 d6 ad 17 74 50 4d 08 8c 38 22 40 98 a7 14 99 |....tPM..8"@....|
Alice020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Bobby020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

So - just from the looks of it, one problem is that identical offset and plaintext (for each 16-byte-block) results in identical ciphertext. If the plaintext differs, so does the ciphertext. In some situations this is may be more revealing than revealing free space.

Another problem is that you can copy ciphertext from one drive to another, and have it decrypt to meaningful data — but on the wrong drive. Normally, if you mess with ciphertext, all you ever get when you decrypt is random garbage, but re-using the masterkey will simply give you more valid ciphertext to work with.

So, completely artificial example, if you have a user who doesn't know the key, but somehow has access to a file stored on this system, and is able to copy ciphertext from one drive to another - normally not possible but let's just assume it is so. They could write a big file full of nonsense, figure out where this file is allocated on disk, then copy the data from the other drives over. And then see another drives data in plaintext when reading their file back in.

Altogether, it's just an unnecessary headache when it's so easy to use a unique key for each disk. Even if you derive that key from a shared master key, using a hash function or whatever. Although there's no reason for that either. You can just use multiple keyfiles, or read multiple keys from a single file using --keyfile-offset, --keyfile-size options.

LUKS is supposed to help you avoid various pitfalls. Unless you deliberately clone the header, it always uses a different, random master key for each container, even if you use the same passphrase for them.

Also a bit of a note on your choice of cipher, aes-xts-plain64. This used to be called aes-xts-plain. And everything was fine until devices larger than 2TiB came about... with aes-xts-plain, ciphertext repeats every 2TiB which is basically the same problem as reusing the same master key.

This was fixed with aes-xts-plain64, but some blogs/wikis still recommend the old one, or old containers are kept and grown along with new harddrives, so some people end up using the wrong one to this day...