No tiene sentido hacer múltiples pases. Una vez es suficiente.
Llenar una unidad para ser encriptada con datos aleatorios tiene principalmente dos usos:
- deshacerse de los datos antiguos y sin cifrar
- hacer que el espacio libre sea indistinguible de los datos cifrados
Por lo general, si cifra, no quiere que nadie vea sus datos. Por lo tanto, es probable que, si tuviera datos antiguos y sin cifrar en esta unidad, también desee deshacerse de ellos. Un SSD podría encargarse de él más fácil y rápidamente blkdiscard
. De hecho, Linux mkfs
TRIM almacena todos los datos sin siquiera pedirle confirmación, lo que hace imposible cualquier tipo de recuperación de datos. Hay demasiado TRIM en Linux.
El espacio libre es un poco gris. Si no rellena previamente con datos aleatorios, en un disco duro nuevo, los sectores en los que nunca se escribieron serán ceros. En un SSD, si permite descartar / TRIM, el espacio libre también será cero.
Si bien esto no afecta sus datos de ninguna manera (todavía está cifrado), revela cuánto espacio libre / datos reales tiene y dónde se encuentra este espacio libre / datos. Por ejemplo, un hexdump -C
SSD recortado y encriptado se verá más o menos así:
# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0 dc c9 c7 89 16 ca d3 4f a3 27 d6 df a0 10 c3 4f |.......O.'.....O|
b3eac000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
b3f70000 5a 99 44 b5 9c 6b 1e 9c 81 cf 9a 43 b6 23 e9 0f |Z.D..k.....C.#..|
b3f70010 2c e6 9a 5d 59 9b 46 5f 21 3f 4d 5f 44 5b 0a 6b |,..]Y.F_!?M_D[.k|
--
b3f70ff0 5f 63 8d e8 c4 10 fd b1 a6 17 b5 7d 4a 57 09 68 |_c.........}JW.h|
b3f71000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
b3f72000 5d 1c 09 dd c9 6b 57 18 db 67 e1 35 81 57 45 8e |]....kW..g.5.WE.|
b3f72010 0f a8 be 39 ae e5 5f cf cf e3 8b a7 c1 25 1a a3 |...9.._......%..|
--
...
De esto se puede decir que tengo segmentos de espacio libre en la dirección 0xb3eac000 .. 0xb3f70000
, b3f71000 .. b3f72000
, ... y la inversa de la que es de segmentos de datos como supuesto 0xb3f70000 .. b3f71000
.
¿Qué puedes hacer con eso? Pues nada(*).
(*) es lo que me gustaría decir. Pero la gente se vuelve creativa . Los patrones de espacio libre se pueden usar para derivar el tipo de sistema de archivos que usa (debido a cómo / dónde almacenan los metadatos; si hay espacio libre donde ext4
almacenaría una de sus copias de seguridad de metadatos, es muy probable que no ext4
, etc.). A veces, incluso revela qué distribución usa (si su instalador de Linux llena el sistema de archivos de manera determinista, los archivos siempre pueden terminar en las mismas direcciones físicas). En ese momento, alguien podría saber dónde se encuentra un archivo de sistema específico y podría modificarlo / dañarlo de alguna manera. (Los instaladores deben aleatorizar la forma en que pueblan los sistemas de archivos para evitar esto).
Sin embargo, tales consideraciones son muy teóricas y de muy bajo riesgo en comparación con la vulnerabilidad de la mayoría de las instalaciones encriptadas debido a otras razones. En la mayoría de las instalaciones listas para usar, es más probable / simple manipular los initramfs, o instalar un keylogger, o explotar el sistema en ejecución, que de alguna manera obtener acceso sin procesar y analizar datos cifrados y esperar lograr algo de esta manera.
Debería preocuparse por estos primero antes de preocuparse por revelar el espacio libre.
Con SSD, es completamente normal habilitar TRIM y, por lo tanto, tener espacio libre revelado en todo momento. Este también es el caso de las soluciones de cifrado que funcionan en una capa de archivo en lugar de en una capa de bloque.
Con HDD, principalmente realiza el borrado aleatorio incluso en un disco nuevo porque puede hacerlo, y no hay razón para no hacerlo, ya que no implica ningún costo (aparte de una configuración inicial) y sin inconvenientes.
badblocks
hace para verificar si hay sectores defectuosos, escribir y verificar 0's, 1's, 01's, 10's. Para el cifrado de disco completo, es común recomendar un relleno cero cifrado (para escribir datos cifrados en todas partes) por las razones en la respuesta de frostschultz (+1), pero hacer todo esto antes del cifrado es inusual, después de cifrar y luego ejecutarbadblocks
o mkfs-cc
lograría lo mismo, además de identificar bloques defectuosos. Tal vez alguien en Kali es un poco paranoico acerca de la memoria flash (USB, SSD) que no siempre escribe el mismo sector en el mismo lugar e intercambia sectores hacia / desde las copias de seguridad