Pre-encryption wipe, why?

There is no point in doing multiple passes. Once is enough.

Filling a to-be-encrypted drive with random data mainly has two uses:

• get rid of old, unencrypted data
• make free space indistuingishable from encrypted data

Usually if you encrypt you don’t want anyone to see your data. So chances are, if you had old, unencrypted data on this drive, you want to get rid of it too. An SSD might take care of it easier and faster with blkdiscard. In fact, Linux mkfs TRIMs all data without even asking you for confirmation, which makes any kind of data recovery impossible. There is too much TRIM in Linux.

Free space is a bit of a grey area. If you don’t pre-fill with random data, on a brand new HDD, sectors that were never written to will be zeroes. On a SSD, if you allow discard/TRIM, free space will also be zero.

While this does not affect your data in any way (it’s still encrypted), it reveals how much free space/actual data you have, and where this free space/data is located. For example a hexdump -C of an encrypted, trimmed SSD will look somewhat like this:

# 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.._......%..|
--
...

From this you can tell I have free space segments at address 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000, … and the inverse of that is of course data segments like 0xb3f70000 .. b3f71000.

What can you do with it? Well, nothing(*).

(*) is what I’d like to say. But people get creative. Free space patterns can be used to derive the type of filesystem you use (due to how/where they store metadata – if there is free space where ext4 would store one of its metadata backups, it’s very likely not ext4, etc.). Sometimes it even reveals which distribution you use (if your Linux installer fills the filesystem deterministically, files might always end up at the same physical addresses). At that point someone might know where a specific system file is located and could modify/damage it in some way. (Installers should randomize the way they populate filesystems to prevent this.)

However such considerations are very theoretical, and very low risk compared to how vulnerable most encrypted installations are due to other reasons. In most out of the box installs, it’s more likely / simpler to just tamper with the initramfs, or install a keylogger, or exploit the running system, than somehow get raw access to and analyze encrypted data and hope to achieve anything this way.

You should worry about these first before worrying about revealing free space.

With SSD, it’s completely normal to enable TRIM and thus have free space revealed at all times. This is also the case for encryption solutions that work on a file layer rather than block layer.

With HDD, you mainly do the random wipe even on a new disk because you can, and there is no reason not to as it involves no cost (aside from a first-time setup) and no downsides.