Dear specialists,
I would like to know, if enabling encryption of Fedora installation in Anaconda installer will dramatically short The life cycle of SSD disk or USB flash drives or SSD memory cart?
By other words. Does enabling encryption enforces much more write requests on file system when comparing with not encrypted partitions?
Thank all engaged Fedora kernel developers for encryption kernel module.
On Sat, Sep 24, 2022 at 11:48 AM Mgr. Janusz Chmiel janusz.chmiel@volny.cz wrote:
Dear specialists,
I would like to know, if enabling encryption of Fedora installationin Anaconda installer will dramatically short The life cycle of SSD disk or USB flash drives or SSD memory cart?
There once were good reasons to be concerned about SSD life cycles, but modern SSD's are much more robust, so now there are other things to worry about like your SSD ending up in the hands of a "bad actor", some filesystem glitch blocking access to encrypted data, etc.
By other words. Does enabling encryption enforces much more write requests on file system when comparing with not encrypted partitions?
Thank all engaged Fedora kernel developers for encryption kernel module.
On 9/24/22 9:47 AM, Mgr. Janusz Chmiel wrote:
Dear specialists,
I would like to know, if enabling encryption of Fedora installation in Anaconda installer will dramatically short The life cycle of SSD disk or USB flash drives or SSD memory cart?
By other words. Does enabling encryption enforces much more write requests on file system when comparing with not encrypted partitions?
Once the encryption is set up, the number of writes will be exactly the same. If you follow the recommendation to fill the device with random data first, that of course is one extra pass of writes over the entire device.
On Sat, 2022-09-24 at 11:14 -0500, Robert Nichols wrote:
If you follow the recommendation to fill the device with random data first
When was that ever recommended, and where?
While a logical thing to do, I've never seen anything or anyone ever say that.
On 9/24/22 9:31 PM, Tim via users wrote:
On Sat, 2022-09-24 at 11:14 -0500, Robert Nichols wrote:
If you follow the recommendation to fill the device with random data first
When was that ever recommended, and where?
While a logical thing to do, I've never seen anything or anyone ever say that.
I recall that recommendation being in the cryptsetup FAQ, but it doesn't seem to be there any more.
A device that was not initialized with random data is going to allow some information about the usage pattern to be leaked. As a simple example, a device that had only been filled only to a small fraction of its capacity would reveal, through the pattern of its metadata blocks, what filesystem was employed. It's the same reason that passthrough of SSD discard (TRIM) commands through the LUKS layer is blocked unless explicitly enabled. (See the comments for the "--allow-discards" option in the cryptsetup manpage for details.)
I doubt that is a practical concern for anyone reading this. I know I don't worry about it.
On 25 Sep 2022, at 04:42, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 9/24/22 9:31 PM, Tim via users wrote:
On Sat, 2022-09-24 at 11:14 -0500, Robert Nichols wrote:
If you follow the recommendation to fill the device with random data first
When was that ever recommended, and where? While a logical thing to do, I've never seen anything or anyone ever say that.
I recall that recommendation being in the cryptsetup FAQ, but it doesn't seem to be there any more.
A device that was not initialized with random data is going to allow some information about the usage pattern to be leaked. As a simple example, a device that had only been filled only to a small fraction of its capacity would reveal, through the pattern of its metadata blocks, what filesystem was employed. It's the same reason that passthrough of SSD discard (TRIM) commands through the LUKS layer is blocked unless explicitly enabled. (See the comments for the "--allow-discards" option in the cryptsetup manpage for details.)
I expect that you can find the usage pattern by accessing the ware levelling data in the SSD. Init with random data will not help on an SSD.
I doubt that is a practical concern for anyone reading this. I know I don't worry about it.
Indeed.
Barry
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Robert Nichols wrote:
On 9/24/22 9:31 PM, Tim via users wrote:
On Sat, 2022-09-24 at 11:14 -0500, Robert Nichols wrote:
If you follow the recommendation to fill the device with random data first
When was that ever recommended, and where?
While a logical thing to do, I've never seen anything or anyone ever say that.
I recall that recommendation being in the cryptsetup FAQ, but it doesn't seem to be there any more.
The end of section 2.1 in the FAQ says:
Alternatively, plain dm-crypt can be used for a very fast wipe with crypto-grade randomness, see Item 2.19
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-...
Similar advvice has been given for as long as I can recall.
For new hdd's, badblocks can be worth running before putting data on the disk and it can write a reasonably random pattern in the process:
badblocks -b 4096 -c 10240 -s -w -t random -v /dev/sdx1
That requires more patience than most folks have, I suspect. It can take around 42 hours for a 16T disk. But then, it's only your data. ;)
There's a long section on drive preparation on the Arch Linux wiki:
https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation
There are, as others already noted, caveats and limitations if using SSD's.
-
Barry Scott -
George N. White III -
Mgr. Janusz Chmiel -
Robert Nichols -
Tim -
Todd Zullinger