Criando um arquivo grande com conteúdo aleatório: atalho copiando?

Question

Suponha que eu queira criar uma grande unidade criptografada armazenada em um arquivo usando cryptsetup, o primeiro passo é criar um arquivo aleatório, suponha que este seja de tamanho 3T:

dd if=/dev/urandom of=$FILE bs=1G count=3000

o processo acima pode levar muito tempo. Eu queria saber se o seguinte atalho faz algum sentido (do ponto de vista da segurança, lembre-se que o objetivo é criar uma unidade criptografada armazenada em $ FILE):

1. dd if=/dev/urandom of=$FILE bs=1G count=1000
2. Faça 3 cópias do arquivo acima, cada arquivo tem tamanho 1T e tem o mesmo conteúdo aleatório
3. Mesclar os 3 arquivos para criar um arquivo aleatório com o tamanho desejado de 3T

Eu acho que esse procedimento não é tão rigoroso quanto os dados são um pouco "menos" aleatórios, mas de um ponto de vista pragmático, essa é uma solução viável (seria quase 3 vezes mais rápida)? Isso é melhor do que criar um arquivo 3T cheio de zeros (usando /dev/zero )?

    

Answer 1

/dev/urandom é muito lento para essa quantidade de dados.

Se o pseudo-aleatório for bom o suficiente:

shred -v -n 1 /kill/me

Se aleatório criptografado é bom o suficiente:

cryptsetup open --type=plain /kill/me cryptkillme
shred -v -n 1 /dev/mapper/cryptkillme
cryptsetup close cryptkillme

A criptografia também é lenta, mas ainda é de ordem mais rápida que /dev/urandom .

shred deve produzir dados aleatórios com rapidez suficiente para qualquer disco.

Observe também que, para esse tamanho, você deve usar um dispositivo de bloco comum, não um arquivo. Se o sistema de arquivos que hospeda o arquivo gigante for corrompido, você verá um quebra-cabeça insolúvel com muitas partes, já que um arquivo desse tamanho geralmente será muito fragmentado.

Se você mantiver o arquivo de qualquer maneira, pode considerar não preenchê-lo com dados aleatórios em primeiro lugar; você poderia usar um arquivo esparso e TRIM / punch_hole para economizar espaço de armazenamento para áreas não utilizadas.

Se a substituição de dados antigos não criptografados fosse o seu objetivo, você teria que substituir todo o espaço livre no sistema de arquivos, não apenas o arquivo contêiner, pois você não saberia se está alocado no mesmo local dos dados não criptografados. você queria se livrar.

    

Answer 2

Respondendo a última parte da sua pergunta: é a sua abordagem (usando os mesmos dados aleatórios três vezes) melhor do que usando zeros.

Na verdade, não é quase o mesmo. Com três partes aleatórias idênticas, cada bloco no seu dispositivo faz parte de um triplo de blocos idênticos. Um invasor pode, portanto, mapear os blocos do seu dispositivo que foram alterados e essa é a mesma informação que o invasor obtém de um dispositivo zerado. Somente quando o seu dispositivo está tão cheio que cada triplo tem três blocos diferentes, isso é quebrado.