urandom vs haveged

[Pádraig Brady]

On 03/26/2012 11:55 PM, Chris Murphy wrote:
> 
> 
> On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:
>>
>> Well if you're just writing huge amounts of "random" data
>> to clear existing space, then you don't need it to be cryptographically secure.
>> Why are you doing this exactly? Would /dev/zero suffice?
> 
> In every supposed best practice case of dm-crypt LUKS setup, urandom is used by example. Including by Red Hat and Fedora Projects. The Fedora link says: "You're looking at a process that takes many hours, but it is imperative to do this in order to have good protection against break-in attempts. Just let it run overnight."
> 
> http://www.redhat.com/summit/2011/presentations/summit/taste_of_training/wednesday/Strickland_On_Disk_Encryption_with_RHEL.pdf
> 
> http://fedoraproject.org/wiki/Implementing_LUKS_Disk_Encryption
> 
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html
> 
> So then the question is, if urandom is what's recommended, are faster substitutes just as good? If they are just as good, then why aren't they the first recommendation? And if this step is superfluous, then I'd suggest documentation be changed to eliminate the suggestion altogether.

Well I can only think of two reasons for writing "random" data.
1. Ensure all existing data is overwritten (zeros would do just as well on modern drives)
2. Homogenize written (with luks data) and nonwritten parts of the drive,
so that you can't determine the extent of the real encrypted data.

I think `shred -v -n1 /your/device` is fine for this:
http://burtleburtle.net/bob/rand/isaacafa.html

cheers,
Pádraig.