Bem, isso não é segurança stackexchange e eu não sou um especialista em criptografia, mas sim:
Alice não criptografada:
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 não criptografado:
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 |................|
Ambos criptografados com a mesma chave (mestre), 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 |................|
Então - apenas pela aparência, um problema é que o deslocamento e o texto simples idênticos (para cada bloco de 16 bytes) resultam em um texto cifrado idêntico. Se o texto plano diferir, o mesmo acontece com o texto cifrado. Em algumas situações, isso pode ser mais revelador do que revelar espaço livre.
Outro problema é que você pode copiar o texto cifrado de uma unidade para outra e tê-lo descriptografado para dados significativos - mas na unidade errada. Normalmente, se você mexer com o texto cifrado, tudo o que você conseguir quando descriptografar é o lixo aleatório, mas reutilizar o masterkey simplesmente lhe dará um texto cifrado mais válido para trabalhar.
Então, exemplo completamente artificial, se você tem um usuário que não conhece a chave, mas de alguma forma tem acesso a um arquivo armazenado neste sistema, e é capaz de copiar texto cifrado de uma unidade para outra - normalmente não é possível, mas vamos apenas supor que é assim. Eles poderiam escrever um arquivo grande cheio de bobagens, descobrir onde esse arquivo está alocado no disco e depois copiar os dados das outras unidades. E, em seguida, ver outra unidade de dados em texto simples ao ler seu arquivo de volta.
No geral, é apenas uma dor de cabeça desnecessária quando é tão fácil usar uma chave exclusiva para cada disco. Mesmo se você deriva essa chave de uma chave mestra compartilhada, usando uma função hash ou qualquer outra coisa. Embora não haja razão para isso também. Você pode usar vários arquivos-chave ou ler várias chaves de um único arquivo usando as opções --keyfile-offset , --keyfile-size .
O LUKS deve ajudá-lo a evitar várias armadilhas. A menos que você clone deliberadamente o cabeçalho, ele sempre usa uma chave mestra aleatória diferente para cada contêiner, mesmo se você usar a mesma frase secreta para eles.
Além disso, uma pequena nota sobre sua escolha de codificação, aes-xts-plain64 . Isso costumava ser chamado de aes-xts-plain . E tudo correu bem até que dispositivos maiores que 2TiB surgiram ... com aes-xts-plain , o texto cifrado repete a cada 2TiB que é basicamente o mesmo problema que reutilizar a mesma chave mestra.
Isso foi corrigido com aes-xts-plain64 , mas alguns blogs / wikis ainda recomendam o antigo, ou contêineres antigos são mantidos e crescidos junto com novos discos rígidos, então algumas pessoas acabam usando o errado até hoje ...