Talk:Dm-crypt/Drive preparation

From ArchWiki

SSD performance

Is it really a good idea to fill an NVME (or SSD) with all random bits as is suggested here? Doing so means that zero blocks are TRIM-ed from the start and it degrades the performance of the NVME drastically.

I went from 2.2 GB/s to 800 MB/s write speed.

CarloWood (talk) 00:05, 4 May 2020 (UTC)Reply[reply]

If you care about security, you need to sacrifice the peak performance (which would go away in any case after you fill the disk with your data). See the warning in Securely wipe disk#Preparations for block device encryption. -- Lahwaacz (talk) 06:30, 4 May 2020 (UTC)Reply[reply]

wipe free space after installation with "cryptsetup reencrypt"

It seems possible to completely wipe free space after installation by performing "cryptsetup reencrypt" or cryptsetup-reencrypt. Compared to the method suggested here, this method assures complete wipe and there's no need to repeat it for each contained volume. However, there's a risk of data loss on system failure. And it could be slower (~50MB/s on a desktop HDD).

I think this is what it does:

 +-------------------------+ decrypt with old volume key +------------+ encrypt with new volume key +--------------------------+
 |Encrypted Data/Free Space|---------------------------->|Data/Garbage|---------------------------->|Encrypted Data/Random Blob|
 +-------------------------+                             +------------+                             +--------------------------+  

I'd like to add it to the article as an alternative. But, I'm not sure if my understanding is correct. Please let me know if something's missed.

Dlight (talk) 10:28, 18 May 2020 (UTC)Reply[reply]

True, you can use reencrypt also for that purpose, I think just linking to Dm-crypt/Device encryption#Re-encrypting devices should be enough, no need to duplicate information here.
Of course using reencrypt is a lot slower than the dd method, not only because of the command itself, but because the data must be backed up beforehand. In fact, it would likely be even slower than just re-luksFormatting and reinstalling the system from scratch, provided that the system wasn't set up much further after installation.
-- Kynikos (talk) 16:07, 19 May 2020 (UTC)Reply[reply]

Wipe LUKS header: a rewrite

Dm-crypt/Drive_preparation#Wipe_LUKS_header is based on guessing header sizes, is using dd, uses it without iflag=fullblock and flushing data to the underlying medium. Since security is at stake, I want this to be reviewed before publication.

(Removed to prevent search engine confusion; see the history for details)

--Mpan (talk) 21:09, 9 December 2020 (UTC)Reply[reply]

Published --Mpan (talk) 02:31, 16 December 2020 (UTC)Reply[reply]