>From ???@??? Tue May 21 10:33:18 2002 X-cs: R From: Yan Fitterer <[EMAIL PROTECTED]> X-RS-ID: <Default> X-RS-Flags: 0,0,1,1,0,0,0 X-RS-Header: In-reply-to: <000501c200ae$b3da1a80$6407070a@blue> X-RS-Sigset: 0 To: "Nicholas Knight" <[EMAIL PROTECTED]> Subject: Re: [tomsrtbt] /dev/random and dd MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Date: Tue, 21 May 2002 11:33:01 -0000
That's very usefull Nicholas - thanks. The goal of this dd was to properly destroy all data on a HD prior to disposal of a machine (old laptops in this case). Zeroing the disk (even repeatedly) isn't really considered good enough, as all bits are affected by the same value, hence my use of a random source. tomsrtbt was an ideal solution: you plug in the old hardware, boot it on the fd, then do a dd. A little change of the scripts could even do this automatically... Am I right then in thinking there's really no easy solution with Linux? (short of leaving the dd running overnight, or mounting the HD in another (faster) machine...) Y. PS - how silly of my not to realise /dev/null was input only... ---- On 21 May 2002, at 3:03, Nicholas Knight wrote: ---- > > > Hi, > > > > I'm trying: > > > > dd if=/dev/random of=/dev/hda bs=1024 > > > > and I get a trickle of random out of /dev/random. Basically, I get a few > records (4 > > or 5) when I break out of it after a few seconds. If I use /dev/urandom I > seem to > > get a little more data, but still _very_ slow. usring /dev/null doesn't > work at all, but > > /dev/zero does. > > > > Timing the process, urandom gives me about 1.8K/s. This running on ancient > > hardware (486). Is the random device that processor-hungry? Or is > something > > else amiss? > > > > I'm on 2.0.103. > > /dev/random attempts to be *really* random. It's ment for situations where > high security is needed, such as key generation for encryption applications. > It spits out a few bytes until it entropy drops too low, then waits for > other events to create additional entropy. Events that qualify are mostly > interrupts, things like moving a mouse or hitting the keyboard. > > /dev/urandom however, does not block. It just keeps spitting out > psuedo-random data that may not be as secure. However, it *will* be slow, > esspecialy on a 486, as it DOES use the same complex algorithim for the data > it spits out as /dev/random. Because of the algorithim it uses, which is > thought to have only some limited theoretical attacks possible at this time, > it can be argued that /dev/urandom is secure enough for just about anything. > > /dev/zero just spits out all zeros, and never blocks. It'll pretty much spit > out zeros as fast as they can be written to disk (or RAM, if you've got room > for the cache). > > /dev/null is *not* an output device, it is input only. Trying to read from > it is useless (picture trying to read from a floppy drive with no diskette > in the drive), it is intended solely as a bit-bucket, whatever is directed > to it is just gone. > > Now, if you want to get a lot of high-entropy random data quickly, you might > look into a hardware-based solution. Some recent motherboards have built-in > random number generators, and I'm pretty sure you can find PCI cards, though > I don't know if any of the PCI cards have Linux drivers avalible. I know the > generator on the Intel chipset does. >
