Description of problem: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html advises: Fill your partition with random data: dd if=/dev/urandom of=/dev/VG00/LV_home This process takes many hours to complete. According to the man page for urandom, the kernel random number generator (/dev/random and /dev/urandom) is intended to supply a small number of bytes of high-quality random data. It is far too expensive to use for the massive quantities of data needed to initialize disk partitions before encrypted filesystems are created there. An appropriate use of /dev/urandom would be to obtain a seed value to use as the argument for the C library srand function, then call the rand function for the large amounts of noise needed to initialize a disk. With disk capacities of multiple terabytes, /dev/urandom could literally take months to generate the necessary amount of data. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 592185 [details] Small C program to quickly generate large amounts of random data.
(In reply to comment #1) > Created attachment 592185 [details] > Small C program to quickly generate large amounts of random data. It would be better, IMO, to use commands that are already in Fedora than to create a separate program. I do agree that we should use something other than urandom, though.
(In reply to comment #2) I agree, but what command? I thought I could write a suitable program more quickly than I might find one, and wished to illustrate an appropriate use of /dev/urandom. Perhaps a reader will suggest a good command for this purpose, something like a feature in palimpsest (or some other application already packaged for Fedora) that efficiently performs this function. The Security Guide should be changed. That is the purpose of this report. Until a good idea is developed for what the Security Guide ought to say, my attachment may help users understand and avoid the days or weeks the current instructions may require to complete.
(In reply to comment #3) > The Security Guide should be changed. That is the purpose of this report. > Until a good idea is developed for what the Security Guide ought to say, my > attachment may help users understand and avoid the days or weeks the current > instructions may require to complete. If you package that program you wrote I'll happily add it to the SG.
I believe we can use 'scrub' to lay down the random bits. I'm going to do some addtional research on this and see if this is an acceptable replacement.
Created attachment 592223 [details] Patch removing dd and adding scrub as a solution. I've created this patch as a recommendation to use scrub instead of dd.
Created attachment 592226 [details] Patch removing dd and adding scrub as a solution. Fixed a DocBook XML tag.
"scrub" should do it. Thank you.
This will be included in the F17 release of the SG.